Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Works platform design principles, approach and rationale
The Works platform design approach is based on the principles of interoperability, open, standards-based, real-time, inclusivity, a single source of truth, security and privacy. The principles define the framework for a scalable and reliable platform that adapts to evolving needs. Read more about the platform design principles here.
Works aim to expedite payments for public works projects undertaken by different departments. The platform registries and APIs ensure units have instant access to trusted information that improves coordination between the various departments. The seamless flow of information ensures payments are fast-tracked, projects are managed better, and departments can execute more work.
The platform design provides the capability to integrate smart payments with iFIX. The integration enables departments to track project milestones and simplify vendor payments. The multi-layer architecture design ensures transparency, visibility and fast decisions all of which translate to an accelerated pace of development. The registries and APIs ensure information flows seamlessly across channels removing the challenges of siloed data structures and facilitating interoperability.
Click on the page link below to learn more about our platform architecture.
The platform architecture illustration below provides a visual representation of the key components and layers that facilitate a seamless flow of information across multiple departments.
The high-level design (refer image above) of the Works System can be divided into three parts:
Master(Reference) Data
Works Registries(Services)
Reused/Enhanced DIGIT Core Services
Below are classifications of some of the master data used in the Works platform. For a comprehensive list, please refer to the service documentation
DIGIT Core service masters are not covered below.
Simple Masters:
Organisation Class
Organisation Functional Area
Organisation Type
Department
Nature of Work
Wage Seeker Skills
Labour Charges
Overheads
Headcodes
Applicable Charges
Mode of Entrustment
Beneficiary Type
Designations
Hierarchical Masters
Type of work
Sub-type of work
Location - Same as DIGIT
Individual - stores details of individual citizens. Individuals may or may not be users of the DIGIT system. If they need login access, they will be created in the User registry.
Organisation - This registry holds details of all types of organisations, their functional areas and class.
Bank Accounts - This registry stores bank account details to be used for online payments in a safe and secure manner.
The following domain services have been developed/are being planned as part of the Works platform:
Project
Estimate
Contracts
Attendance
Muster roll
Expense/Billing
JIT Adapter (Roadmap)
Milestones (roadmap)
Payment Calendar (roadmap)
Measurement Book (roadmap)
The following list consists of major core services from DIGIT that will be reused in Works Project. A few of the common core services might have been missed from the list.
The Works platform hosts the below registries:
- contains a detailed description of a citizen/individual who may/may not interact directly with the DIGIT platform but is a beneficiary.
- contains the organisation details.
- contains tenant/organisation bank account details.
Base Path: /org-services/organisation
Raw API spec resides here. To view in the Swagger editor, click below:
To be added.
Click to learn more about this service.
Describes a calculator service for computing attendance
The muster roll service aggregates attendance logs from the attendance service based on some rules and presents an attendance aggregate for a time period (week or month) per individual. This can then be used to compute payments or other semantics.
DIGIT backbone services
Idgen
Persister
Indexer
Workflow
User
Attendance
/muster-roll
This service models estimates for Works projects
Estimate Service will allow users to create estimates and forward them for approval to higher authorities across departments for technical, financial, and admin sanctions. For more technical information on this service, please refer to the and the folder.
Project
MDMS
Workflow
Notification
Access Control
User
IDGen
Base Path: /estimates/
The diagram below shows the interaction between the estimate service and the persister, indexer. This does not follow the default pattern. Instead, enrichment of the payload for the indexer happens via a separate consumer and then the enriched payload is pushed to a topic. The indexer listens to this topic and sends it to ElasticSearch.
An inbox is needed when there is a workflow-enabled for the service.
The proposed sequence diagram is below.
TBD
Estimate inbox uses the Inbox V2 service (from DIGIT core) which queries ES to retrieve details for the inbox. For more information on Inbox V2, please refer .
Indexer Config: