Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
The attendance service provides generic attendance logging functionality based on "in" and "out" timestamps. IN and OUT timestamps are recorded per individual. Aggregating and calculating attendance based on these timestamps is the function of the muster roll service.
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.
/attendance/v1/
Below are the variables that should be configured for the contract service in the Helm environment file prior to deployment. The Helm environment file will be located under:
https://github.com/
{{ORG}}
/DIGIT-DevOps/deploy-as-code/helm/environments/
{{EnvironmentFile}}
.yaml
Please refer to a 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, please add the way it's done here.
Make sure to add the DB(Postgres and flyway) username & password in the respective environment secret yaml file the way it's done here.
Make sure to add the digit core services related secrets 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 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
Make sure the id format is configured in the IdFormat.json file of the common-masters
module in MDMS.
Please 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
Sample postman collections are here to demonstrate integration with the attendance service.
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. This service is shared across multiple eGov missions. The source code for this service resides . For a deeper understanding, please refer to the following:
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.
Common steps to configure platform services
This page lists common configuration steps that need to be repeatedly performed for all services. Please follow these steps in the context of each service replacing only certain values as needed. The respective service will provide you with information on what needs to be replaced.
Deploying a service involves three parts:
Deploying a published docker image of the service in the DIGIT environment
Having the Helm charts are necessary for the service deployment. Helm charts configure the environment variables for the service specific to a Kube cluster. A service can be deployed using OR directly using Helm commands from a system. All helm charts for services are .
Configuring the service
Set up , , , other masters for the service to work properly on GitHub.
to find detailed information on MDMS configuration.
All modules expose certain actions (APIs), roles (actors) and role-action mappings (who can access which resource). Role-action mappings are used for access control.
Each service documentation has a role-action table that identifies the actors that can access the resource. Follow the outline below replacing specific actions/roles for each module.
Actions, roles and role-action mapping are defined within a master tenant in folders. The folders have the same name as the module name for easy identification.
Example:
In the above image, "pg" is the state level tenant. The three folders highlighted in orange contain the masters for actions, roleactions and roles respectively.
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. 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 given below:
Configure roles based on 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
A sample set of role-action entries is shown below. Each of the actionid
fields needs to match a corresponding API from the actions.json file.
In the example below the ESTIMATE_CREATOR
is given access to API actionid 9. This maps to the estimate create 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.
Please add that yaml file under the configs repository if not present already.
Make sure to restart MDMS and the persister service after adding the file at the above location.
Roles | APIs /Actions |
---|---|
IDGen format for attendance register number |
---|
Role Code | Description | API |
---|
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. The associated are provided here for reference. Use these to understand the request payloads.
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
{
"format": "WR/[fy:yyyy-yy]/[cy:MM]/[cy:dd]/[SEQ_ATTENDANCE_REGISTER_NUM]",
"idname": "attendance.register.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 |
Detailed description of configuring the contract service
The contract service provides the functionality of a works contract.
A running DIGIT platform is needed to deploy the contract service. Specifically, the following dependencies are needed:
Estimate
Organisation
User
Workflow
IDGen
Notification
Persister
Indexer
This service provides APIs to create, update and search for contracts. Please refer to the functional specifications for detailed scope and functionality. Low-level technical design is available here.
Below are the variables that should be configured for the contract service in the Helm environment file prior to deployment. The Helm environment file will be located under:
https://github.com/
{{ORG}}
/DIGIT-DevOps/deploy-as-code/helm/environments/
{{EnvironmentFile}}
.yaml
Please refer to a sample here.
Add db-host,db-name,db-url,domain and all the digit core platform services configurations (Idgen, workflow,user etc.) in the YAML file.
Add contract-service related environment variables’ value like the way it's done in ‘dev’ environment yaml file. Search for "contract-service" in the file.
Add the ‘egov-mdms-service’ related configuration to the respective environment yaml file. Make sure you change the gitsync.branch name.
Check the contract-service persister file is added in the egov-persister.perister-yml-path
variable. If not, please add the way it's done here.
Make sure to add the DB(Postgres and flyway) username & password in the respective environment secret yaml file the way it's done here.
Make sure to add the digit core services related secrets 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 after the above changes are performed.
Configure actions, roles and role-action mappings from the table below. Follow the steps here.
These have to be translated into JSON in the role-action mapping module in MDMS.
Example is here.
The following masters are to be added as per the table below:
Make sure the id format is configured in the ‘IdFormat.json’ file of the ‘common-masters’ module. Sample is here.
The following Workflow JSON needs to be put in the request body of the /egov-workflow-v2/egov-wf/businessservice/_create
API.
For more information on configuring workflow, please refer to the Workflow Service documentation here.
Sample CURL is also included below.
Note that authToken and other requestInfo parameters should be updated as per your environment.
Please make sure that the file contract-service-persister.yml is present in the configs
repository in the below location.
https://github.com/<YOUR ORGANISATION>/works-configs/tree/DEV/egov-persister
If not present, please make sure to add the persister YML file.
Make sure to restart MDMS and the persister service after adding the file at the above location.
Please make sure that the file contractservices-indexer.yml is present in the configs
repository in the below location.
https://github.com/{{your organisation}}/works-configs/tree/DEV/egov-indexer
In the MDMS repository, locate the inbox configuration file. Make sure the following JSON is added to the inbox configuration:
Restart the Inbox service after updating above configuration
The API specifications for this service are located here. Postman scripts are also provided here for reference to understand the request payloads.
Muster roll is a record of attendance and quantity of work done by wage seekers.
A muster roll is a record of attendance, wages due and the quantity of work done by labour for a specific period of time.
The attendance service provides raw attendance logs. The muster roll service aggregates attendance logs and computes attendance based on business logic. For eg., whether attendance is to be measured in hours or days, what is considered a half day or a full day of attendance etc.. is business logic that will vary between implementations. These are configurable in this service and calculations on attendance will be performed based on these configurations.
Attendance
Individual
Persister
MDMS
Workflow
Idgen
Notification
Provides APIs to:
Estimate wages of a wage seeker based on his/her attendance logs
Create a muster roll with a list of wage seekers
Update a muster roll with modified aggregate attendance
Search for a muster roll based on some defined parameters. For more info, please see Swagger contract.
Below are the variables that should be configured for the muster roll service in the Helm environment file prior to deployment. The Helm environment file will be located under:
https://github.com/
{{ORG}}
/DIGIT-DevOps/deploy-as-code/helm/environments/
{{EnvironmentFile}}
.yaml
Please refer to a 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 muster-roll-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 muster-roll-service persister file is added in the egov-persister.perister-yml-path
variable. If not, please add the way it's done here.
Make sure to add the DB(Postgres and flyway) username & password in the respective environment secret yaml file the way it's done here.
Make sure to add the digit core services related secrets are configured in the respective environment secret file the way it's done here.
Add all the APIs exposed (refer to 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 ‘Muster Environment’.
3. MusterRoll requires the below services from 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 ‘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.
Provides an overview of the configuration of the estimate service
The estimate service provides the functionality to create, update and search for estimates related to a Works project. An estimate is always linked to a project. For low-level technical design, please refer to this section.
The following services need to be running for the estimate service to function:
DIGIT backbone services (PostgreSQL, Elastic Search, Zuul)
Project
MDMS
Persister
Indexer
Workflow
User
Please refer to the functional specifications for an overview of functionality provided by this service.
Configure roles, actions and role-action mappings as per the table below by referring to this doc here:
Sample is 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 steps here for configuring this.
Please ensure the below files are present in https://github.com/egovernments/works-configs/blob/DEV/egov-indexer/estimateservices-indexer.yml
If 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 please ensure, you have done the below configs
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.
Please add inbox-v2 configuration in a respective environment in MDMS as it has done in here. Below are the inbox configuration for the Estimate service:
to
Below are the variables that should be configured well before 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, please add the way it's done here.
Make sure to add the DB(Postgres and flyway) username & password in respective environment secret yaml file the way it's done here.
Make sure to add the digit core services related secrets are configured in the respective environment secret file the way it's done here.
Postman scripts for Estimate are here:
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, community based organisations in the Works domain. This registry stores information about an organisation including their contact details, tax identifiers, areas of work and other relevant information.
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.
The Helm chart for this service is configured here.
Configure roles, actions and role-actions per the table below by following steps here.
Make sure organisation-persister.yml is present in the configs repo under the egov-persister directory.
Please 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.
Role | APIs |
---|---|
IDGen Format |
---|
Roles | API Endpoints |
---|---|
Role | APIs |
---|---|
Roles | API Endpoints |
---|---|
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
CBO Roles
OCI Roles
ContractType
Overheads
{
"format": "WO/[fy:yyyy-yy]/[SEQ_CONTRACT_NUM]",
"idname": "contract.number"
}
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
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
WORK_ORDER_CREATOR
MUKTA_ADMIN
/org-services/organisation/v1/_search
MUKTA_ADMIN
/org-services/organisation/v1/_create
MUKTA_ADMIN
/org-services/organisation/v1/_update
Estimate
Contract
Attendance
Muster Roll
Expense
Bank Account
Organisation
Individual
Project