Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The attendance service provides generic attendance logging functionality for recording "in" and "out" timestamps for individuals. These timestamps are logged on a per-individual basis. The muster roll service takes on the responsibility of aggregating and calculating attendance based on these recorded timestamps. It processes and computes attendance data using these individual "in" and "out" timestamps to provide a comprehensive view of attendance records.
A running DIGIT platform is needed to deploy the attendance service. Specifically, the following dependencies are needed:
Individual
MDMS
Idgen
Persister
Indexer
Provides APIs to:
Create an attendance register
Map staff to the register
Map attendees to the register
Log attendance
Edit attendance registers, staff, attendees and attendance.
Code
Base URL: /attendance/v1/
Below are the variables that should be configured for the contract service in the Helm environment file before deployment. The below path is used to locate the Helm environment file.
https://github.com/{{ORG}}/DIGIT-DevOps/deploy-as-code/helm/environments/{{EnvironmentFile}}.yaml
Refer to the sample here.
Add these ‘db-host’,’db-name’,’db-url’, ’domain’ and all the digit core platform services configurations (Idgen, workflow, user etc.) in respective environments YAML file.
Add attendance-service related environment variables’ value like the way it's done in the ‘dev’ environment YAML file.
Add the ‘egov-mdms-service’ related configuration to the respective environment YAML file. Make sure you change the gitsync.branch name.
Check the attendance-service persister file is added in the egov-persister.perister-yml-path variable. If not, follow the steps outlined here.
Make sure to add the DB(Postgres and flyway) username & password in the respective environment secret YAML file as per the steps given here.
Make sure to add the DIGIT core services-related secrets that are configured in the respective environment secret file the way it's done here.
Restart egov-mdms-service, egov-persister, egov-indexer, inbox, egov-workflow-v2, egov-accesscontrol and ZUUL services after the above changes are performed.
Add all the APIs exposed by the attendance service (refer to the table below for actual APIs) to the actions.json file in MDMS
Module name: ACCESSCONTROL-ACTIONS-TEST
Master name: actions-test
Configure roles based on the roles column below in roles.json file.
Module name: ACCESSCONTROL-ROLES
Master name: roles
Role-action mapping is configured in MDMS per the table below .
Module name: ACCESSCONTROL-ROLEACTIONS
Master name: roleactions.json
ORG_ADMIN
JUNIOR_ENGINEER
MUNICIPAL_ENGINEER
/attendance/v1/_create
ORG_ADMIN
JUNIOR_ENGINEER
MUNICIPAL_ENGINEER
/attendance/v1/_update
ORG_ADMIN
JUNIOR_ENGINEER
MUNICIPAL_ENGINEER
/attendance/v1/_search
ORG_ADMIN
ORG_STAFF
/attendance/staff/v1/_create
ORG_ADMIN
ORG_STAFF
/attendance/staff/v1/_delete
ORG_ADMIN
ORG_STAFF
/attendance/attendee/v1/_create
ORG_ADMIN
ORG_STAFF
/attendance/attendee/v1/_delete
ORG_ADMIN
ORG_STAFF
/attendance/log/v1/_create
ORG_ADMIN
ORG_STAFF
/attendance/log/v1/_search
ORG_ADMIN
ORG_STAFF
/attendance/log/v1/_update
Make sure the id format is configured in the IdFormat.json file of the common-masters module in MDMS.
{
"format": "WR/[fy:yyyy-yy]/[cy:MM]/[cy:dd]/[SEQ_ATTENDANCE_REGISTER_NUM]",
"idname": "attendance.register.number"
}
Make sure that the file attendance-service-persister.yml is present in the MDMS repository of the organisation: https://github.com/{{ORG}}/works-configs/tree/<BRANCH>/egov-persister
/attendance/
Sample postman collections are here to demonstrate integration with the attendance service.
Provides an overview of the configuration of the estimate service
Estimate Service allows users to create estimates and forward them for Workflow approval to higher authorities across departments for technical, financial, and admin sanctions. A prepared estimate can then be tendered out for contracting.
Refer to the low-level technical design documentation for more information on estimate service.
Refer to the functional specifications for details on the capabilities supported by this service.
The following services need to be running for the Estimate Service to function:
Project
MDMS
Workflow
Notification
Access Control
User
IDGen
mdmsV2
Contract Service
Measurement Service
DIGIT backbone services (PostgreSQL, Elastic Search, Zuul)
Persister
Indexer
Create/update/search for Work estimates for a project.
Allows upload of offline documents related to estimate creation as part of Create.
Workflow and inbox integration
Create/update/search for Work Revised Estimate for an existing approved estimate.
Code
Configure roles, actions and role-action mappings as per the table below by referring to this document:
ESTIMATE_CREATOR
/estimate-service/estimate/v1/_create
/estimate-service/estimate/v1/_search
/wms/estimate/_search
ESTIMATE_VERIFIER
/estimate-service/estimate/v1/_update
/estimate-service/estimate/v1/_search
/wms/estimate/_search
TECHNICAL_SANCTIONER
/estimate-service/estimate/v1/_update
/estimate-service/estimate/v1/_search
/wms/estimate/_search
ESTIMATE_APPROVER
/estimate-service/estimate/v1/_update
/estimate-service/estimate/v1/_search
/wms/estimate/_search
ESTIMATE_VIEWER
/estimate-service/estimate/v1/_search
/wms/estimate/_search
EMPLOYEE_COMMON
/inbox/v2/_search
Refer to the sample here.
The persister file for the service is called estimate-service.yml.
https://github.com/egovernments/works-configs/blob/DEV/egov-persister/estimate-service.yml
Follow the steps here for configuring this.
Ensure the below files are present in https://github.com/egovernments/works-configs/blob/DEV/egov-indexer/estimateservices-indexer.yml
In case the above files are not present, add them in the given location and restart the ‘egov-indexer’ service in the respective environment. Before restarting the service ensure the below configurations are done.
Note: Add this config in the respective environment YAML file in the DevOps repository and then deploy the service.
In the common-masters folder of MDMS, locate the IDFormat.json file. ID formats should be configured for the Estimate number as well as Estimate Detail objects. Make sure the following lines are added and the format modified per implementation:
The following masters need to be configured for the Estimate service. Please make sure to use the same master name and module names:
The workflow configuration for Estimate is as follows. This payload needs to be called against businessService _create API for workflow configuration:
Inbox should be configured if Workflow is configured for the Estimate Service. If there is no workflow involved, this can be skipped.
Add the inbox-v2 configuration in a respective environment in MDMS as it has been done here. Below is the inbox configuration for the Estimate service:
to
The below variables should be configured well before the deployment of the estimate service build image. These are configured in the DevOps repository:
Add these ‘db-host’,’db-name’,’db-url’, ’domain’ and all the digit core platform services configurations (Idgen, workflow, user etc.) in respective environments YAML file.
Add estimate-service related environment variables’ value like the way it's done in ‘dev’ environment YAML file.
Add the ‘egov-mdms-service’ related configuration to the respective environment YAML file. Make sure you change the gitsync.branch name.
Check the estimate-service persister file is added in the egov-persister.perister-yml-path variable. If not, follow the steps outlined here.
Make sure to add the DB (Postgres and flyway) username & password in the respective environment secret YAML file. Follow the steps given here.
Ensure the DIGIT core services-related secrets are added to the respective environment secret file. Follow the steps given here.
Base Path: /estimates/
Postman collection for this service is available here.
Detailed description of configuring the contract service
The contract service captures work orders or purchase orders. It validates the work order against the estimate(s). Line items from one estimate can be put in a contract. Line items from multiple estimates can be aggregated into one work order as well. The contract service validates the line items from each estimate as part of Create and Update.
A running DIGIT platform is needed to deploy the contract service. Specifically, the following dependencies are needed:
Estimate
Organisation
User
Workflow
IDGen
HRMS
Notification
Persister
Indexer
This service provides APIs to create, update and search for contracts.
Models a real-world work order/contract
All line items of a single estimate can be put in a contract.
Line items from multiple estimates can also be grouped into a contract.
The service validates the estimate line items and ensures no duplication happens in including estimate line items in a contract.
Terms and conditions, milestones and payment calendar are WIP
Add configurations for db-host, db-name, db-url, domain, and core platform services (Idgen, workflow, user, etc.) in the YAML file.
Search for "contract-service" in the environment YAML file. Add the contract-service environment variables similar to how it’s done in other entries.
Restart egov-mdms-service, egov-persister, egov-indexer, inbox, egov-workflow-v2, egov-accesscontrol and zuul after the above changes are performed.
These have to be translated into JSON in the role-action mapping module in MDMS.
Add the following masters as per the links below:
The following workflow JSON needs to be put in the request body of the /egov-workflow-v2/egov-wf/businessservice/_create API.
Sample CURL is also included below.
Note that authToken and other requestInfo parameters should be updated as per your environment.
Sample CURL is also included below.
Note that authToken and other requestInfo parameters should be updated as per your environment.
In case it is not available, add the persister YML file.
Make sure to restart MDMS and the persister service after adding the file at the above location.
Restart the Inbox service after updating the above configuration
Muster roll is a record of attendance and quantity of work done by wage seekers.
A muster roll serves as a record of attendance, indicating the hours worked, wages owed, and the amount of work completed by labourers during a specified time frame.
The attendance service supplies raw attendance logs, while the muster roll service collects these logs and calculates attendance according to specific business rules. For instance, determining whether attendance is measured in hours or days and defining what constitutes a half-day or a full day of attendance are decisions that depend on the specific implementation. These configurations can be adjusted within the service, and attendance calculations will be carried out based on these settings.
Attendance
Individual
Persister
MDMS
Workflow
Idgen
Notification
The functionality includes the following APIs:
Estimate Wages: This API calculates the wages for a wage seeker based on their attendance logs.
Create Muster Roll: It allows you to create a muster roll, which is essentially a list of wage seekers.
Update Muster Roll: You can use this API to update a muster roll with modified aggregate attendance data.
Search for Muster Roll: This API enables you to search for a muster roll using specific parameters. For more details, you can refer to the Swagger contract.
Code
Here is a list of variables that needs to be configured in the Helm environment file before deploying the muster roll service. This file can typically be found under a specific directory or location as given below:
https://github.com/{{ORG}}/DIGIT-DevOps/deploy-as-code/helm/environments/{{EnvironmentFile}}.yaml
Add these ‘db-host’,’db-name’,’db-url’, ’domain’ and all the digit core platform services configurations (Idgen, workflow, user etc.) in respective environments yaml file.
Add all the APIs exposed (refer to the table below for actual APIs) to the actions.json file in MDMS
Module name: ACCESSCONTROL-ACTIONS-TEST
Master name: actions-test
Configure roles based on the roles column below in roles.json file.
Module name: ACCESSCONTROL-ROLES
Master name: roles
Role-action mapping is configured in MDMS per the table below.
Module name: ACCESSCONTROL-ROLEACTIONS
Master name: roleactions.json
Other muster roll masters are configured in the common-masters folder:
1. Import the postman collection for muster roll service into the Postman application.
2. Import the environment variables required for running the Postman collection. This will create an environment by the name of Muster Environment in Postman.
3. MusterRoll requires the below services from the Attendance Service API to be run. So run the below services before running the muster roll postman collection.
a) Create Attendance register - https://{hostname}/attendance/v1/_create
b) Enroll attendees to the register - https://{{hostname}}/attendance/attendee/v1/_create
c) Attendance log create - https://{{hostname}}/attendance/log/v1/_create
4. Update the current value of the variable ‘registerId’ in ‘Muster Environment’ with the id returned by the response in the create attendance register (in step 3 a).
5. Run the ‘Muster Roll Service’ postman collection as ‘Run Collection’. It will run the /_estimate, /_create, /_update and /_search API’s success and validation error scenarios.
6. Muster will be created for the attendees enrolled in the attendance register (in step 3 b) using the attendance logs created (in step 3 c).
The current value of environment variables ‘musterRollId’ and ‘musterRollNumber’ will be set from the response of the /_create muster roll which will be used by /_update and /_search APIs.
The expense module implements the functionality of bills and payments. A bill or a group of bills can be aggregated together as payments. Payment advice can be submitted through integration with IFMS (Integrated Financial Management Systems) or any other third-party payment provider. The expense module always works in combination with a calculator service. The calculator service is implementation-specific and provides business logic to compute bills. The calculator calls into the expense service to create bills. In general, the expense create/update APIs are not called by any other module other than the calculator.
to browse for more information on the sample calculator provided with the Works platform.
DIGIT backbone services
Persister
Indexer
IDGen
MDMS
Workflow
Notification
Create/update/search functionality for bills
Ability to create different bill types according to configuration.
The workflow is integrated and needs to be configured for usage.
Works with an expense calculator that contains the business logic to compute bills.
Code
Steps to configure the project service
The project service provides APIs to create, update and manage a generic project. A project can have one or more of the following constructs: staff, tasks, beneficiaries and facilities. Currently, this service is shared across the Health and Works platforms. All Works projects start with a project construct. The Works platform uses only 3 primary APIs: project create, update and search.
For a deeper understanding, refer to the following:
Creating, updating, and searching for a project
Adding staff, tasks, resources and facilities to a project
Code
Define (if not present already) and assign the EMPLOYEE_COMMON role to all project actors.
Below are the actions or APIs exposed by the Project service used by the Works platform. Note that the "id" in the attributes needs to be unique and may be different in the implementation environment. It need not be exactly the same as what is shown below.
The following table shows the mapping between the APIs and the roles:
The following role-action mappings derived from the above table are configured for the Project service in the roleactions.json in MDMS. A sample is provided below. Make sure the action ID is correct and corresponds to actions.json.
The image name of the service is available in the release charts in the DevOps repository. The service can be deployed using Helm commands.
Environment variables to be configured in the Helm chart for the service are:
Add the ‘db-host’,’db-name’,’db-url’,’domain’ and all the digit core platform services configurations (Idgen, workflow, user etc.) in respective environments yaml file.
NOTE: Restart egov-mdms-service, egov-accesscontrol, egov-persister, audit-service, egov-indexer and zuul after the above changes are performed.
Base path: /project/
The bank accounts registry houses the financial account details of individual and organisational entities. The registry stores the account name, type, bank branch identifier (IFSC code) and other optional information. The bank branch identifier can be configured as master data. This makes it easy to extend this registry for use in countries outside India. The registry encrypts all PII and stores it securely.
DIGIT backbone services
Persister
Encryption
Stores bank account details of entities in a secure fashion.
All PII data is encrypted securely.
Code
for deployment
Base path: /bankaccount-service/bankaccount
Common steps to configure Works services
On this page, you will find a set of standard configuration steps that should be applied consistently across all services. Make sure you adhere to the below steps within the context of each service, making necessary replacements only as instructed by the respective service's guidelines.
Steps:
Deploying a service encompasses three key aspects:
Service Image Deployment: This entails deploying a published Docker image of the service within the DIGIT environment.
Service Configuration: To ensure the service functions seamlessly, it is essential to configure it correctly. This includes setting up MDMS, IDGen, Workflow, and other masters as necessary, all of which can be done on GitHub.
In summary, deploying a service involves these three fundamental steps, each contributing to the successful deployment and operation of the service within the DIGIT environment.
Each module offers specific actions (APIs), roles (actors), and role-action mappings (defining access permissions). Role-action mappings control the access and permissions for each role. Each service documentation contains the role-action table that specifies the actors authorized to access particular resources. Adhere to the structure below, substituting specific actions and roles as required for each module.
Actions, roles, and role-action mappings are organised within the master tenant and corresponding folders. These folders are conveniently named after the module, making it easy for users to identify.
Example:
In the image above, "pg" represents the state-level tenant. The highlighted orange folders contain the masters for actions, role actions, and roles.
Folder structures are only for categorisation and easy navigation of master files. The MDMS service retrieves data only through module and master names. Make sure that these are correct.
Add all the APIs exposed by the service (refer to service for actual APIs) to the actions.json file in MDMS.
Keep appending new entries to the bottom of the file.
Make sure the id field is unique. The best practice is to increment the ID by one when adding a new entry. This id field will be used in the role-action mapping.
Module name: ACCESSCONTROL-ACTIONS-TEST
Master name: actions-test
In case 403s are encountered despite configuration, double-check the actions.json file to make sure the API in question has a unique ID. In case of duplicate IDs, a 403 will be thrown by Zuul.
A sample entry is given below:
Configure roles based on the details given in the roles column (refer to service documentation) in the roles.json file. Make sure the role does not exist already. Append new roles to the bottom of the file.
Module name: ACCESSCONTROL-ROLES
Master name: roles
A sample entry is given below:
Role-action mapping should be configured as per the role-action table defined. Add new entries to the bottom of the roleactions.json file.
Identify the action ID (from the actions.json file) and map roles to that ID. If multiple roles are mapped to an API, then each of them becomes a unique entry in the roleactions.json file.
Module name: ACCESSCONTROL-ROLEACTIONS
Master name: roleactions.json
Example: A sample set of role-action entries is shown in the code block below. Each of the actionid fields should match a corresponding API in the actions.json file.
In the example below, the ESTIMATE_CREATOR is given access to API actionid 9. This maps to the estimate created API in our repository.
Note that the actionid and tenantId might differ from implementation to implementation.
Each service has a persister.yaml file which needs to be stored in the configs repository. The actual file will be mentioned in the service documentation.
Add this YAML file to the configs repository if not present already.
Make sure to restart MDMS and the persister service after adding the file in the above location.
Configuring platform services
Click on the doc link below to access the service configuration details for the platform services.
Click on the individual service links below to access the Mukta-specific service configuration details.
Refer to the for detailed scope and functionality. Low-level technical design is
Code -
The variables below should be configured for the contract service in the Helm environment file before deployment. to find the Helm environment file.
Refer to the .
Add the ‘’ related configuration to the respective environment YAML file. Make sure you change the gitsync.branch name.
Check the contract-service persister file is added to the egov-persister.perister-yml-path variable. If not, update the values as given .
Make sure to add the DB (Postgres and flyway) username & password in the respective environment secret YAML file. Refer to the details given .
Make sure to add the DIGIT core services-related secrets configured in the respective environment secret file. Refer to the details given .
Configure actions, roles and role-action mappings from the table below. Refer to the details available .
Example - available .
Make sure the id format is configured in the ‘IdFormat.json’ file of the ‘common-masters’ module. The sample .
For more information on configuring workflow, refer to the documentation.
Make sure that the file is present in the configs repository in the below location.
Make sure that the is present in the .
In the MDMS repository, locate the. Make sure the following JSON is added to the inbox configuration:
The API specifications for this service are located .
to access the Postman scripts to understand the request payloads.
Refer to the .
Add muster-roll-service related environment variables’ value like the way it's done in the’ environment yaml file.
Add the related configuration to the respective environment YAML file. Make sure you change the gitsync.branch name.
Check the muster-roll-service persister file is added to the egov-persister.perister-yml-path variable. If not, follow the steps outlined.
Make sure to add the DB(Postgres and flyway) username & password in the respective environment secret YAML file as per the steps outlined.
Make sure to add the digit core services-related secrets that are configured in the respective environment secret file as per the steps outlined.
Add Id Format as configured in the ‘IdFormat.json’ file of the ‘common-masters’ module . This format is used to generate the unique ID of the project.
Add persister file as defined .
Add indexer file as defined .
1.
2.
3.
4.
Add project-management-system related environment variables values. A sample from a’ environment yaml file is provided below:
Add the ‘’ related configuration to the respective environment yaml file. Make sure you change the git-sync branch name to one that is appropriate for the environment.
Check the project management system persister file is added in the egov-persister.persister-yml-path variable. If not, please add the way it's done .
Check the project management system indexer file is added in the egov-indexer.egov-indexer-yaml-repo-path variable. If not, please add the way it's done .
Check the project management system persister file is added in the audit-service.persist-yml-path variable. If not, please add the way it's done .
Make sure to add the DB(Postgres and flyway) username & password in the respective environment secrets yaml file the way it's done.
Make sure to add the DIGIT core service-related secrets that are configured in the respective environment secret file the way it's done.
Refer to the for a description of the APIs.
Documentation for this service is available .
Click to access the Postman collection used to test APIs. Import the link into Postman and follow the instructions to run the collection. Use these to understand the request payloads.
Helm Charts Requirement: Helm charts play a crucial role in service deployment as they configure environment variables tailored to the specific Kubernetes cluster. You can deploy a service either through CI/CD pipelines or directly by utilizing Helm commands from your system. All helm charts for services are .
to find detailed information on MDMS configuration.
WORK_ORDER_CREATOR
/contract/v1/_create
/contract/v1/_update
/contract/v1/_search
/wms/contract/_search
WORK_ORDER_VERIFIER
/contract/v1/_update
/contract/v1/_search
/wms/contract/_search
WORK_ORDER_APPROVER
/contract/v1/_update
/contract/v1/_search
WORK_ORDER_VIEWER
/contract/v1/_search
/wms/contract/_search
EMPLOYEE_COMMON
/inbox/v2/_search
{
"format": "WO/[fy:yyyy-yy]/[SEQ_CONTRACT_NUM]",
"idname": "contract.number"
} {
"format": "RW/[fy:yyyy-yy]/[SEQ_CONT_SUPPLEMENT_NUM]",
"idname": "contract.supplement.number"
}
PROJECT_CREATOR
Project Creator
/project/v1/_create
/project/v1/_update
/project/v1/_search
PROJECT_VIEWER
Project Viewer
/project/v1/_search
EMPLOYEE_COMMON
Employee Common
/inbox/v2/_search
ORG_ADMIN
ORG_STAFF
/muster-roll/v1/_estimate
ORG_ADMIN
ORG_STAFF
/muster-roll/v1/_create
ORG_ADMIN
ORG_STAFF
MUSTER_ROLL_VERIFIER
MUSTER_ROLL_APPROVER
/muster-roll/v1/_update
ORG_ADMIN
ORG_STAFF
MUSTER_ROLL_VERIFIER
MUSTER_ROLL_APPROVER
BILL_CREATOR
BILL_VIEWER
/muster-roll/v1/_search
The individual registry provides APIs to create citizens or users on the DIGIT platform.
Refer to this page for steps to configure and deploy the Individual registry.
Organisation registry to store vendors, contractors, CBOs and other org types.
The organisation service is a generic registry to store all types of organisations. This includes vendors, contractors, and community-based organisations in the Works domain. This registry stores information about an organisation including their contact details, tax identifiers, work areas and other relevant information.
The below services need to be running in the environment for the organisation registry to function as expected:
Persister
Indexer
User
Individual
MDMS
Access Control
Notification
IDGen
Filestore
Provides APIs to create, update and search an organisation's details. As part of organisation creation, it also creates a system user who can log into the DIGIT system and perform actions on behalf of the organisation. The contact person details are used to create the user with a CITIZEN role and an OTP-based login.
Code
The Helm chart for this service is configured here.
Configure roles, actions and role-actions per the table below by following the steps below.
WORK_ORDER_CREATOR
MUKTA_ADMIN
/org-services/organisation/v1/_search
MUKTA_ADMIN
/org-services/organisation/v1/_create
MUKTA_ADMIN
/org-services/organisation/v1/_update
Make sure organisation-persister.yml is present in the configs repo under the egov-persister directory.
Make sure that the file organisationservices-indexer.yml is present in the configs repo under the egov-indexer directory.
The following ID formats are configured for the Organisation service under the common-masters directory, IDFormat.json file. Make sure these are present in the file.
SMS templates have to be configured with the service provider to send notifications to users. Current SMS template configurations are as follows:
Download the Postman collection for this service and test the APIs against a DIGIT server.
Estimate
Contract
Attendance
Muster Roll
Expense
Bank Account
Organisation
Individual
Requirement of creating an estimate template that can be used to create an estimate, This template has SOR and NON-SOR line items, which will be copied while creating an estimate.
Why Choose MDMS V2?
According to the requirement, the Estimate service has no dependency on other services. The only dependency is with SOR which is a part of MDMS-V2. It stores the data and for that the MDMS service is sufficient. We finalized this approach to reduce the overhead of creating and maintaining a new service.
Figma Design
