Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Loading...
Here are the articles in this section:
We have introduced an enhanced service, Project Factory, along with a Console Web Application, to streamline the campaign setup and update processes.
Project Factory The Project Factory simplifies the campaign setup process by automating several key tasks:
Boundary Creation: Generates boundary entities and establishes boundary relationships based on Excel input.
Localization: Creates localized names for boundaries.
User Management: Enables the creation of users.
Facility Creation: Facilitates the setup of facilities.
Project Creation: Allows the creation of campaign-specific projects based on the selected hierarchy and target.
Project Mapping: Establishes mappings between projects, users, and facilities to ensure seamless campaign execution.
Console The Console Web Application enables users to:
Set up initial boundaries.
Create campaigns.
Configure delivery rules.
Create products.
Set boundary targets.
Create facilities and link them to respective boundaries.
Create users and map staff to boundaries.
Connect with the Project Factory service to create campaigns in DIGIT HCM.
Enhancements in Version 0.3 In version 0.3, we introduced several key features:
Support for editing campaign data.
Boundary management capabilities.
Checklist configuration options.
Fetching data from approved Microplans for campaign creation.
Standardized naming for the localization module.
Support for IRS campaigns.
A dual timeline view for better campaign monitoring and management.
We have introduced a new service project-factory and console web to streamline the campaign setup process.
Project factory enhanced to support the timeline view of processes.
The console web application will have the support to extend/update dates for an ongoing campaign.
The Console now shows the timeline view of processes going on in the creation of a campaign.
We have introduced a new service project-factory and console web to streamline the campaign setup process
Project-factory helps users create the seed data necessary for the campaign creation process in DIGIT HCM. Additionally, it helps establish relationships between all the resources.CommentDepends on the Latest Health Services (Integrated with Boundary V2),
The console web application assists users with the initial boundary setup, campaign creation, delivery rule configuration, product creation, boundary target setting, facility creation and linking for each boundary, user creation, staff mapping for each boundary, and connecting with the project-factory service to create campaigns in DIGIT HCM.
The development is complete for all the features that are part of the release.
Yes
The code freeze occurred on Dec 9th
Test cases are documented by the QA team, reviewed by product owners, and test results are updated in the test cases sheet.
Yes
Lata
All test cases are reviewed by the Product Owner and results have been updated in the sheet. QA sign-off is given accordingly @lata check and update the status
The incremental demo of the features showcased during the sprint showcase and feedback is incorporated. If possible, list out the JIRA tickets for feedback.
Yes
Jagan and Team
Sprint Demo v0.3 Admin Console: Tuesday, October 15, 12:00 – 1:00pm
Sprint Demo v0.3 Admin Console: Monday, October 28, 4:00 – 5:00pm
Incremental Handover of HCM Console v0.3: Tuesday, November 5, 4:15 – 5:00pm
Admin Console Sprint Demo: Wednesday, November 13, 5:00 – 6:30pm
Incremental Handover of HCM Console v0.3 - Session 2: Friday, November 15, 4:30 – 5:00pm
Impel Handover HCM Microplan & Console: Monday, November 25⋅3:30 – 4:30pm
We had the following incremental demos with the product owner:
UI/UX audit review is completed along with feedback incorporation for any changes in UI/UX.
Yes
Bhavya
@ AndrewJones
UI/UX audit done, and feedbacks incorporated 1st review - 29oct
Follow up review - 12 Nov
@bhavya update the status and link
Incremental demos to the product owners are completed as part of the sprint, and feedback is incorporated.
Yes
Lata
@lata / satya add the dates of incremental handovers
QA sign-off is completed by the QA team and communicated to product owners. All the tickets’ QA sign-off status is updated in JIRA.
Yes
Lata
Conditional QA Signoff on Nov 13, 2024
QA sign-off was completed on Nov 27, 2024.
UI, and API technical documents are updated for the release along with the configuration documents.
Yes
Nitish Bhavya
UAT promotion and regression testing from the QA team is completed. The QA team has shared the UAT regression test cases with the product owners.
Yes
Lata
UAT Promotion: Nov 14 - Nov 16
UAT Testing Completion: Nov 27
API automation scripts are updated for new APIs or changes to any existing APIs for the release. API automation regression is completed on UAT; the automation test results are analysed and the necessary actions are taken to fix the failure cases. Publish the list of failure use cases with a reason for failure and the resolution taken to fix these failures for the release.
Yes
Lata/
The API backward compatibility testing is completed.
Lata
The communication is shared with product owners for the completion of UAT promotion and regression by the QA team. The product owners have to give a product sign-off within one week of this communication.
Yes
Yes
Lata
Communication is shared with PO: Wed Nov 20
The UAT product sign-off communication is received from product owners along with the release notes and user guides (if applicable).
Yes
The GIT tags and releases are created for the code changes for the release.
Yes
Verify whether the release notes are updated.
Yes
Nitish
Verify whether all the UAT builds are updated along with the GIT tag details.
Yes
Nitish
Verify whether all MDMS, configurations, infra-ops configurations are updated.
Yes
Nitish
Yes
Mihika
In progress - review pending
Verify whether all test cases are up-to-date and updated along with the necessary permissions to view the test cases sheet. The test cases sheet is verified by the test lead.
Yes
Lata
Verify whether the UAT credentials' sheet is updated with the details of new users and roles, if any.
This should not go into Gitbook as this is internal to eGov.
Lata
Verify whether all the localisation data was added in UAT, and updated in the release kits.
Lata
Verify whether the product release notes and user guides are updated and published.
The demo of the released features is done by the product team as part of a sprint/release showcase.
Yes
Yes
Technical and product workshops/demos are conducted by the engineering and product teams respectively to the implementation team (implementation handover).
Yes
@Ankit Sharma
HCM Admin Console Final Handover to Impel Team Date: May 30
Architect sign-off and technical quality report.
Verify Bug Bash has been completed
Yes
Product roadmap and success metrics.
Yes
Yes
Vignesh
Adoption metrics.
Ankit
Programme roll-out plan.
Ankit
Ranjani
Implementation plan/checklist
Ankit
Ranjani
Gate 2
Yes
Vignesh
ExCos
June 20
The internal release communication along with all the release artefacts are shared by the engineering/ product teams.
Vignesh
To be shared post Gate 2
Devops
project-factory values
Config
project-factory persister
For MDMS-V2 changes, refer to the file below for MDMS schema and data that needs to be added for health - HCM-ADMIN-CONSOLE service:
Changes are being tracked in the Excel sheet:
V0.3 Test Cases
This release will let the user - who is a System Administrator - set up campaigns on the and will reduce the current setup time for a given campaign from about 15 days to about 2-3 days.
Some of the known issues(Change Requests have been created) related to this release are:
Redirecting user from Date change confirmation screen to "Campaign Summary" screen
Seeing updated dates on Campaign Summary screen
Allowing users to configure app features (Checklist).
Allowing users to update the Ongoing Campaign Data
This release introduces the following key capabilities for users:
Boundary Data Management:
Empowering countries to manage their own data by creating a dedicated user role responsible for all Master Data, starting with boundary data. Future releases will extend this to Facility, Product, and Vehicle Masters.
Supporting GIS-based MicroPlanning by enabling boundary setup through ShapeFiles or GeoJSONs, laying the groundwork for future enhancements.
Campaign Data Editing: Users can edit data for upcoming or ongoing campaigns, including:
Campaign and Cycle Dates
User data (add/edit/delete app users)
Target data
Facility data
Boundary data (select from existing boundaries)
Checklist Management: System admins can create custom checklists for specific users at different boundary hierarchy levels using the forms engine.
Dual Timelines for Campaign Creation: Enhancing campaign creation processes by integrating with HCM MicroPlanning
The features under this release will be considered a success if we have the following outcomes post the release:
Time for campaign configuration for Post Intervention flows reduces from 1 week to less than an hour
Requests for our implementation team to edit the following data points for a campaign fall to zero:
Edit Campaign and Cycle Dates
Edit User Data
Edit Target Data
Edit Facility Data
Edit Boundary Data
This release will let the user - who is a System Administrator - set up campaigns on the and will reduce the current setup time for a given campaign from about 15 days to about 2-3 days
Some of the known issues related to this release are:Comment
Usability of the Excel templates: The usability of the Excel templates for setting targets, facility data, and user data could be improved as the inputs in the Excel from the users are not restricted in the sheet and could lead to errors
Decentralising the data setup process.
Changing dates for ongoing campaigns from the Console.
Allowing users to configure app features.
3
Verify whether all docs will be published to by the Technical Writer as part of the release.
3
,
HCM Admin Console Incremental Handover Date: May 16 Date: Jun 21
/
Features
Description
IRS Campaign Capability on Console
Enabling the IRS Campaign Capability on Admin Console. Now Users can plan IRS campaign through Admin Console
Editing User's, Facilities, Targets
Edit data for an already existing campaign (either an upcoming or ongoing campaign). Under this capability the user will be able to edit the Campaign and Cycle Dates, Edit User Data,Edit Target Data, Edit Facility Data, Edit Boundary Data
Boundary Data Management
As a step towards building capacity and managing/creating their own data a new user is being created which would be solely responsible for managing all Master Data, starting with boundary data in this release - next releases will cover Facility Master, Product Master and Vehicle Master. All the master data configured here will be used by the whole HCM Stack - Microplanning, Campaign Creation through Console, HCM App and Dashboards.
Checklist Management
For every new campaign we need to configure checklists which are created for different users at different levels of boundary hierarchies. We need to provide the capability for System Admins, where the system admins can create their own checklists for specific users at specific levels of boundary hierarchy using forms engine capabilities.
Admin Console Integration with Microplanning
Features
Description
Update Dates
Updating Dates for upcoming or ongoing campaign
Timeline
Timeline view for campaign creation process
Usablity Fixes on Excel Templates
MDMS Data on User and Facility Sheets as Dropdowns
Features
Description
Campaign name
The system admin can set the name of the campaign being created.
Campaign start and end dates
The system admin can set when the campaign starts and ends in the system.
Number of cycles, number of deliveries in each cycle, and dates for each cycle
The system admin can set the number of cycles and deliveries and dates for each cycle in the system.
Setting delivery rules for each delivery
Using the attributes and mathematical operators, the system admin can set the delivery rules for each delivery, and create eligibility criteria for all deliveries.
Selecting boundaries for campaign through UI
The user can select the boundaries where the campaign will be done through UI.
Setting targets at the lowest level of boundary data
A system admin can set the targets at the lowest level of boundary data by uploading target data on Excel template upload.
Creating facility data
A system admin can create or choose to reuse the existing facility data with the help of an Excel template upload.
Creating user data
A system admin can create the user data with the help of an Excel template upload.
When dealing with large-scale data creation on a server based on Excel input, the choice between Python and Node.js depends on factors like performance, ecosystem support, scalability, and ease of development.
Here’s a breakdown of both languages for this use case:
Strengths:
Performance: Java delivers high performance for CPU-bound tasks due to its compiled nature and efficient memory management (JVM).
Scalability: Java is a proven choice for large-scale enterprise systems, supporting high concurrency via multi-threading and frameworks like Spring Boot and WebFlux.
Stability: Java is ideal for enterprise-grade applications requiring strict type safety and long-term stability.
Weaknesses:
Verbose Development: Java requires more boilerplate code and setup, slowing down initial development compared to Python or Node.js.
Complexity for I/O: Non-blocking I/O requires additional frameworks like Netty or reactive programming (WebFlux), adding complexity.
Startup Time: Java services have longer initialization times and higher memory usage compared to Node.js.
Excel Processing are often more complex and resource-intensive when processing large Excel datasets even with help of Libraries like Apache POI and JExcel .
Advantages:
Event-Driven & Non-Blocking I/O: Node.js is excellent for I/O-heavy operations such as sending HTTP requests or interacting with APIs/servers concurrently.
Concurrency: With its single-threaded event loop and libraries like async/await, Node.js is efficient for tasks that involve network operations.
Excel Processing Libraries: Node.js has libraries like xlsx and exceljs for reading and writing Excel files. While they are performant, they are not as feature-rich as Python’s pandas.
Stream Support: Node.js natively supports streams, allowing large files to be processed in chunks without loading them fully into memory.
Scalability: Node.js performs well under high loads and can handle a massive number of concurrent connections due to its lightweight architecture.
Disadvantages:
Data Processing: Node.js lacks the robust and mature data manipulation libraries Python offers (e.g., pandas), making it less efficient for complex data transformations.
CPU-Bound Operations: Node.js struggles with CPU-intensive tasks like large-scale data processing since it is single-threaded by default. This can be mitigated using worker threads.
Advantages:
Excel Handling Libraries: Python has excellent libraries like pandas, openpyxl, and xlrd for reading, manipulating, and writing Excel files efficiently.
Data Manipulation: Python excels at processing and analyzing large datasets due to its data science-oriented libraries like pandas, NumPy, and Dask (for parallel processing).
Built-in Support for Parallelism: Libraries like multiprocessing or concurrent.futures allow Python to distribute processing of huge datasets across CPU cores.
Ease of Development: Python’s simplicity and extensive ecosystem make it easier to implement and test scripts for such tasks.
Data Export: Python can easily integrate with databases, APIs, or servers for data creation through libraries like requests (HTTP requests) or sqlalchemy (database connections).
Disadvantages:
Slower Execution Speed: Python’s Global Interpreter Lock (GIL) can limit concurrency for I/O-heavy tasks, though libraries like asyncio and threading help mitigate this.
Memory Management: Python can use more memory for extremely large datasets compared to Node.js.
Scalability: If you need to process millions of concurrent requests, Python may require more effort to scale.
The task is I/O-intensive (e.g., creating data on other servers via HTTP APIs).
You need high concurrency and scalability.
You are working with large Excel files and want to leverage streaming to avoid loading entire files into memory.
You are already using a Node.js-based ecosystem and prefer to keep it consistent.
You need to process and transform huge datasets in Excel efficiently.
Your task involves heavy data manipulation or analytics.
You prefer working with established libraries like pandas and openpyxl.
Your use case is CPU-bound rather than I/O-bound (e.g., processing Excel locally before sending data to a server).
For complex use cases, you can use both:
Use Python for preprocessing and transforming large Excel files.
Use Node.js for efficient HTTP requests to create data on other servers.
If your task involves heavy Excel processing and transformations: Use Python.
If your task focuses on sending data concurrently to other servers: Use Node.js.
If both Excel processing and data creation are important and you’re comfortable with Python, it’s often the better choice due to its ecosystem and ease of data manipulation
Conclusion
Considering the above points, we chose a Node.js implementation for the Project Factory Service. This service involves boundary creation based on the input Excel file, project creation for selected boundaries within a campaign, and the creation of entities such as facilities, users, and the necessary mappings between the created projects and these entities. We utilized the exceljs library to process the input Excel data for entity information, and we have observed that the total data creation like project, project mapping for 3000+ boundaries is completed within 15 minutes with high concurrency.
Name of the field
Description
Mandatory or Optional
Input
Validation
Need Data from programme/state?
Campaign type
Specific campaign run by the system admin.
Mandatory
User
Yes
Campaign name
Name given to the campaign being created.
Mandatory
User
Yes
Beneficiary type
Specify the beneficiaries for the campaign. For example, household, individual, structure.
Mandatory
Auto Selected by the system
No
Start and end dates of the campaign
This will define when the campaign starts and ends.
Mandatory for moving to the next step.
User
Yes
Number of cycles in the campaign
This will set the number of cycles in the campaign.
Mandatory for moving to the next step
User
Yes
Number of deliveries in each cycle in the campaign
This will set the number of deliveries in each cycle of the campaign.
Mandatory for moving to the next step
User
Yes
Dates for each cycle
This will set the dates of cycles in each cycle of the campaign.
Mandatory for campaign creation, non mandatory to move to the next step
User
Yes
Selecting parameters for delivery rules
These are the parameters basis which a user can create the delivery rules.
Mandatory for moving to the next step
User
Yes
Selecting operators for delivery rules
These are the operators basis which a user can create the delivery rules.
Mandatory for moving to the next step
User
Yes
Configuring resources for delivery
These are the products/resources that are going to be delivered to the beneficiary during the campaign.
Mandatory for moving to the next step
User
Yes
Selection of the boundary information
The user will select boundaries where the user wants to select the boundary.
Mandatory for moving to the next step
User
Yes
Setting of targets
The user will enter boundary-wise targets in an Excel template.
Mandatory for campaign creation, non mandatory to move to the next step
User
Yes
Creating facility data
The user will enter the facility data in an Excel template.
Mandatory for campaign creation, non mandatory to move to the next step
User
Yes
Creating user data
The system admin will enter the user data in an Excel template.
Mandatory for campaign creation, non mandatory to move to the next step
User
Yes
The development is complete for all the features that are part of the release.
Yes
The code freeze occurred on Jun 20
Test cases are documented by the QA team, reviewed by product owners, and test results are updated in the test cases sheet.
Yes
@shreya
All test cases are reviewed by the Product Owner and results have been updated in the sheet. QA sign-off is given accordingly
The incremental demo of the features showcased during the sprint showcase and feedback is incorporated. If possible, list out the JIRA tickets for feedback.
Yes
Jagan and Team
We had the following incremental demos with the product owner:
HCM Campaign Screens Preview: April 10, 5:00 – 5:30pm
HCM Campaign Manager Demo: April 15, 2:00 – 3:00pm
End-to-End Flow of HCM Admin Console: April 29, 3:00 – 4:00pm
Final HCM Admin Console Demo: May 10, 4:00 – 4:45pm
Incremental Performance Improvement on HCM Admin Console Demo: Jun 11, 3:00 – 4.00pm
Performance Improvement Changes on HCM Admin Console Demo: Jun 14, 12:00 – 12:45pm
UI/UX audit review is completed along with feedback incorporation for any changes in UI/UX.
Yes
Nabeel
@ AndrewJones
Incremental demos to the product owners are completed as part of the sprint, and feedback is incorporated.
Yes
Shreya
QA sign-off is completed by the QA team and communicated to product owners. All the tickets’ QA sign-off status is updated in JIRA.
Yes
shreya
QA sign-off was completed on May 9, 2024.
UI, and API technical documents are updated for the release along with the configuration documents.
Yes
Ashish Nabeel
UAT promotion and regression testing from the QA team is completed. The QA team has shared the UAT regression test cases with the product owners.
Yes
Shreya
UAT sign-off was completed on May 23, 2024.
API automation scripts are updated for new APIs or changes to any existing APIs for the release. API automation regression is completed on UAT; the automation test results are analysed and the necessary actions are taken to fix the failure cases. Publish the list of failure use cases with a reason for failure and the resolution taken to fix these failures for the release.
Yes
Shreya
The API backward compatibility testing is completed.
shreya
Not Applicable, since it is new service
The communication is shared with product owners for the completion of UAT promotion and regression by the QA team. The product owners have to give a product sign-off within one week of this communication.
Yes
Yes
shreya
UAT sign-off was completed on May 23, 2024.
The UAT product sign-off communication is received from product owners along with the release notes and user guides (if applicable).
Yes
The GIT tags and releases are created for the code changes for the release.
Yes
Verify whether the release notes are updated.
Yes
Ashish
Verify whether all the UAT builds are updated along with the GIT tag details.
Yes
Ashish
Verify whether all MDMS, configurations, infra-ops configurations are updated.
Yes
Ashish
Yes
Mihika
In progress - review pending
Verify whether all test cases are up-to-date and updated along with the necessary permissions to view the test cases sheet. The test cases sheet is verified by the test lead.
Yes
Shreya
Verify whether the UAT credentials' sheet is updated with the details of new users and roles, if any.
This should not go into Gitbook as this is internal to eGov.
Shreya
Verify whether all the localisation data was added in UAT, and updated in the release kits.
shreya
Verify whether the product release notes and user guides are updated and published.
The demo of the released features is done by the product team as part of a sprint/release showcase.
Yes
Yes
Technical and product workshops/demos are conducted by the engineering and product teams respectively to the implementation team (implementation handover).
Yes
@Ankit Sharma
HCM Admin Console Final Handover to Impel Team Date: May 30
Architect sign-off and technical quality report.
Verify Bug Bash has been completed
Yes
Bug bash done on 21 May 2024
Product roadmap and success metrics.
Yes
Yes
Vignesh
Adoption metrics.
Ankit
Programme roll-out plan.
Ankit
Ranjani
Implementation plan/checklist
Ankit
Ranjani
Gate 2
Yes
Vignesh
ExCos
June 20
The internal release communication along with all the release artefacts are shared by the engineering/ product teams.
Vignesh
To be shared post Gate 2
boundary persister
boundary persister
project-factory persister
project-factory persister
For MDMS-V2 changes, refer to the file below for MDMS schema and data that needs to be added for health - HCM-ADMIN-CONSOLE service: Refer here to get all the MDMSv2 schemas and data.
Data for schema HCM-ADMIN-CONSOLE.attributeConfig
Data for schema HCM-ADMIN-CONSOLE.deliveryTypeConfig
Data for schema HCM-ADMIN-CONSOLE.deliveryConfig
Data for schema HCM-ADMIN-CONSOLE.facilityschema
Data for schema HCM-ADMIN-CONSOLE.adminSchema
Data for schema HCM-ADMIN-CONSOLE.baseTimeout
Data for schema HCM-ADMIN-CONSOLE.mailConfig
Data for schema HCM-ADMIN-CONSOLE.operatorConfig
Data for schema HCM-ADMIN-CONSOLE.productType
Data for schema HCM-ADMIN-CONSOLE.readMeConfig
Data for schema HCM-ADMIN-CONSOLE.Boundary
Data for schema HCM-ADMIN-CONSOLE.hierarchyConfig
Data for schema HCM-ADMIN-CONSOLE.userSchema
data/pg/ACCESSCONTROL-ACTIONS-TEST/actions-test.json
data/pg/ACCESSCONTROL-ROLES/roles.json:
This document outlines the flow for updating an existing campaign using various services in the system. The process involves interactions between multiple services, including the Project Factory, Project Service, Boundary Service, Facility Service, HRMS Service, MDMS Service, FileStore Service, and the database. The update flow ensures that the required resources are validated and updated correctly before finalizing the campaign update.
Client: The entity (user or system) initiating the campaign update request.
CampaignManager (Project Factory): The main controller managing the campaign update process.
ProjectService: Manages project-related operations, including data creation and mapping updates.
BoundaryService: Handles fetching of boundary relationships based on hierarchy types.
FacilityService: Responsible for creating and updating facility-related data.
HRMSService: Manages the creation and updating of employee data.
MDMSService: Provides master data such as project types.
FileStoreService: Manages the storage and retrieval of resource files.
Database: Stores campaign-related data and status updates.
Initiate Campaign Update
The Client sends an update request to the CampaignManager with all required and valid resources.
Fetch Boundary Relationship
The CampaignManager requests the BoundaryService to fetch the boundary relationship based on the hierarchy type.
The BoundaryService responds with the relevant boundary relationship data.
Fetch Project Type Master
The CampaignManager requests the MDMSService to fetch the project type master data.
The MDMSService responds with the project type master.
Validate Resource Files
The CampaignManager queries the Database to check if the input resource files have already been validated.
The Database responds with the validation status of the files.
Fetch Parent Campaign Object
The CampaignManager queries the Database to fetch the parent campaign object based on the parentCampaignId.
The Database responds with the parent campaign object.
Validation Check
The CampaignManager checks if all file templates and data are validated:
If validation is successful, the CampaignManager informs the Client that the campaign update process has started, and the user needs to track the status using an ID.
If validation fails, the CampaignManager returns an error message, indicating which validation failed, and the user must resubmit the request.
Deactivate Parent Campaign
The CampaignManager updates the Database to mark the parent campaign object as inactive.
Retrieve Resource Files
The CampaignManager interacts with the FileStoreService to search for the resource based on the filestoreid.
The FileStoreService responds with the valid resource files.
Process Resource Data
The CampaignManager processes the retrieved sheets to identify any resource data that needs to be created.
Facility Data Creation
The CampaignManager sends a request to the FacilityService to create facility data.
The FacilityService responds that the facilities have been created successfully.
Employee Data Creation
The CampaignManager sends a request to the HRMSService to create employee data.
The HRMSService responds that the employees have been created successfully.
Search for Parent Project
The CampaignManager sends a request to the ProjectService to search for the previous or parent project.
The ProjectService responds with the project object.
Create New Projects for Added Boundaries
The CampaignManager copies the project content from the parent project while creating new projects for newly added boundaries.
The CampaignManager sends a request to the ProjectService to create project data for newly added boundary data and map it according to its parent.
The ProjectService responds that the projects have been created successfully.
Update Facility Data
The CampaignManager identifies what exact data needs to be updated for facilities.
The CampaignManager sends a request to the ProjectService to create project-facility mapping if any new facilities are added.
The ProjectService responds that the project-facility mapping has been created successfully.
The CampaignManager sends a request to the ProjectService to search for the previous project-facility mapping.
The ProjectService responds with the project-facility mapping data.
The CampaignManager sends a request to the ProjectService to update the project-facility mapping.
The ProjectService responds that the project-facility mapping has been updated successfully.
Update Staff Data
The CampaignManager identifies what exact data needs to be updated for staff.
The CampaignManager sends a request to the ProjectService to create project-staff mapping if any new staff are added.
The ProjectService responds that the project-staff mapping has been created successfully.
The CampaignManager sends a request to the ProjectService to search for the previous project-staff mapping.
The ProjectService responds with the project-staff mapping data.
The CampaignManager sends a request to the ProjectService to update the project-staff mapping.
The ProjectService responds that the project-staff mapping has been updated successfully.
Update Campaign Status
The CampaignManager updates the Database with the campaign update status.
Validation Failure: If any validation step fails (e.g., invalid data in resource files or missing required resources), the CampaignManager sends an error message to the Client, indicating the failure. The user is required to fix the issues and resubmit the request.
Service Errors: If any of the service interactions (e.g., BoundaryService, MDMSService, ProjectService) return an error, the CampaignManager stops the process and informs the Client of the failure, specifying the nature of the error.
Database Errors: If the Database fails to update the campaign update status or mark the parent campaign as inactive, appropriate error handling and logging mechanisms should be triggered to handle the failure.
This document provides a comprehensive overview of the update campaign flow, detailing each step and interaction between different services and the database. The flow ensures proper validation and updating of necessary resources, while error handling mechanisms provide robustness to the process.
This document outlines the flow for creating a campaign using various services in the system. The process involves interactions between multiple services, including the Project Factory, Project Service, Boundary Service, Facility Service, HRMS Service, MDMS Service, FileStore Service, and the database. This flow ensures that the required resources are validated and correctly set up before finalizing the campaign creation.
Client: The entity (user or system) initiating the campaign creation request.
CampaignManager (Project Factory): The main controller managing the campaign creation process.
ProjectService: Manages project-related operations, including data creation and mapping.
BoundaryService: Handles fetching of boundary relationships based on hierarchy types.
FacilityService: Responsible for creating facility-related data.
HRMSService: Manages the creation of employee data.
MDMSService: Provides master data such as project types.
FileStoreService: Manages the storage and retrieval of resource files.
Database: Stores campaign-related data and status updates.
Initiate Campaign Creation
The Client sends a request to the CampaignManager to create a campaign with all required and valid resources.
Fetch Boundary Relationship
The CampaignManager requests the BoundaryService to fetch the boundary relationship based on the hierarchy type.
The BoundaryService responds with the relevant boundary relationship data.
Fetch Project Type Master
The CampaignManager requests the MDMSService to fetch the project type master data.
The MDMSService responds with the project type master.
Validate Resource Files
The CampaignManager checks the Database to see if the input resource files have already been validated.
The Database responds with the validation status of the files.
Validation Check
The CampaignManager checks if all file templates and data are validated:
If validation is successful, the CampaignManager informs the Client that the campaign creation process has started, and the user needs to track the status using an ID.
If validation fails, the CampaignManager returns an error message, indicating which validation failed, and the user must resubmit the request.
Resource File Retrieval
The CampaignManager interacts with the FileStoreService to search for the resource based on the filestoreid.
The FileStoreService responds with the valid resource files.
Process Resource Data
The CampaignManager processes the retrieved sheets and identifies any resource data that needs to be created.
Facility Data Creation
The CampaignManager sends a request to the FacilityService to create facility data.
The FacilityService responds that the facilities have been created successfully.
Employee Data Creation
The CampaignManager sends a request to the HRMSService to create employee data.
The HRMSService responds that the employees have been created successfully.
Project Data Creation
The CampaignManager sends a request to the ProjectService to create project data with a parent-child relationship based on the project type and delivery configuration.
The ProjectService responds that the projects have been created successfully.
Project-Facility Mapping Creation
The CampaignManager sends a request to the ProjectService to create mappings between projects and facilities.
The ProjectService responds that the project-facility mappings have been created successfully.
Project-Staff Mapping Creation
The CampaignManager sends a request to the ProjectService to create mappings between projects and staff.
The ProjectService responds that the project-staff mappings have been created successfully.
Update Campaign Creation Status
The CampaignManager updates the Database with the status of the campaign creation process.
Validation Failure: If any validation step fails (e.g., invalid data in resource files), the CampaignManager sends an error message to the Client, indicating the failure. The user is required to fix the issues and resubmit the request.
Service Errors: If any of the service interactions (e.g., BoundaryService, MDMSService) return an error, the CampaignManager stops the process and informs the Client of the failure, specifying the nature of the error.
Database Errors: If the Database fails to update the campaign creation status, appropriate error handling and logging mechanisms should be triggered to handle the failure.
This document provides an overview of the create campaign flow, detailing each step and interaction between different services and the database. The flow ensures proper validation and creation of necessary resources, while error handling mechanisms provide robustness to the process.
Project-factory assists users in generating the seed data essential for the campaign creation process in DIGIT HCM and in establishing relationships between all resources. The Project Factory Service manages project-type campaigns by handling the creation, updating, searching, and campaign setup processes. This documentation details the available APIs, their endpoints, request and response structures, and internal processing flows.
Knowledge of JavaScript (preferably ES6).
Knowledge of Git or any version control system.
Knowledge of RESTful web services.
Knowledge of the Kafka and Postgres.
Knowledge of eGov-mdms service, eGov-persister, eGov-idgen, eGov-indexer, and eGov-user will be helpful.
project-factory/v1/
TO DO add other information
Swagger :
Configure the role CAMPAIGN_MANAGER for project-factory in the ‘ACCESSCONTROL-ROLES’ module.
Configure the action id(s) with the corresponding role code ‘ACCESSCONTROL-ROLEACTIONS’ module.
For Project Factory Service Role-Action mappings are as follows in the Dev environment.
API EndPoints
Roles
/project-factory/v1/project-type/create
CAMPAIGN_MANAGER
/project-factory/v1/project-type/update
CAMPAIGN_MANAGER
/project-factory/v1/project-type/search
CAMPAIGN_MANAGER
/project-factory/v1/data/_create
CAMPAIGN_MANAGER
/project-factory/v1/data/_search
CAMPAIGN_MANAGER
/project-factory/v1/data/_generate
CAMPAIGN_MANAGER
/project-factory/v1/data/_download
CAMPAIGN_MANAGER
Additional APIs being used are:
API EndPoints
Roles
/boundary-service/boundary-hierarchy-definition/_search
CAMPAIGN_MANAGER
boundary-service/boundary-relationships/_search
CAMPAIGN_MANAGER
/product/variant/v1/_search
CAMPAIGN_MANAGER
/product/v1/_search
CAMPAIGN_MANAGER
/product/v1/_create
CAMPAIGN_MANAGER
/product/variant/v1/_create
CAMPAIGN_MANAGER
Configure all the MDMS data for project factory service as done in the QA environment.
Data to configure :
Attribute Config
Boundary Schema
Delivery Config
Facility Schema
Gender Config
Mail Config
Operator Config
Product Type
User Schema
Refer to the following:
https://github.com/egovernments/egov-mdms-data/tree/UNIFIED-QA/data/mz/health/hcm-admin-console
Make sure the id format is configured in the ‘IdFormat.json’ file of the ‘common-masters’ module.
Below is what is currently configured in the QA environment.
Environment variables Below are the variables that should be configured well before deployment of the project factory service build image.
Add these ‘db-host’,’db-name’,’db-url’,’domain’ and all the digit core platform services configurations (Idgen ,persister, filestore, etc.) in respective environments yaml file.
Add project factory service related environment variables’ value like the way it's done in the QA environment yaml file. (Search for project-factory)
Heath-hrms, health-project, health-individual and facility should have specified heap and memory limits as mentioned below
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.
Click here for localisation details.
Click here to get the Postman Collection
This document outlines the web flow for managing checklists within a campaign context, including viewing existing and creating new checklists. The process involves interaction between the user and various backend services to ensure the correct retrieval, creation, and modification of checklists associated with specific campaigns.
User: The individual interacting with the checklist management UI to view, create, and modify checklists.
Checklist View UI (CurrentScreen): This is the user interface for viewing existing checklists and initiating the creation of new ones.
Checklist Create UI (CurrentScreen): The user interface for creating and configuring checklists.
Service Request Service (ServiceRequestService): Manages service requests and updates related to checklists.
MDMS Service (MDMSAPI): Provides master data management services for roles, checklist types, and other configurations.
Localisation Service (LOCAPI): Manages the localization of checklist questions.
Access Checklist View UI
The user accesses the Checklist View UI after a campaign has been created.
Fetching Configured Service Requests
CurrentScreen sends a request to ServiceRequestService to fetch configured service requests.
ServiceRequestService filters and returns checklists using the campaign name, role, and type, or just the campaign name (if the service is enhanced).
ServiceRequestService returns the relevant checklists to CurrentScreen.
Display Checklists
CurrentScreen displays the checklists received from ServiceRequestService to the User.
Creating a New Checklist
The user clicks on "Create Checklist" in the Checklist View UI.
CurrentScreen sends a request to MDMSAPI to fetch role and checklist type master data relevant to the campaign type.
MDMSAPI returns the master data to CurrentScreen.
The user selects the desired role and checklist type.
CurrentScreen redirects to the checklist creation screen based on the selected campaign name, role, and type.
Enable/Disable Checklist
The user clicks on the enable/disable option for any checklist.
CurrentScreen sends an update call to ServiceRequestService to toggle the active/inactive status of the checklist.
ServiceRequestService returns the updated response.
CurrentScreen updates the checklist status based on the response.
Access Checklist Create UI
The user accesses the Checklist Create UI.
CurrentScreen parses URL query parameters to determine the campaign name, role, and checklist type.
Fetching Draft Service Requests
CurrentScreen sends a request to MDMSAPI to fetch draft service requests based on the role and type.
MDMSAPI returns the configured draft service requests.
Loading Default Checklist Questions
CurrentScreen checks if there is a template available for the checklist and loads default checklist questions.
User Interaction for Checklist Questions
Users can add, delete, or modify any checklist questions in the UI.
The user clicks on "Create" to finalise the checklist.
Generating Unique Codes and Creating Service Requests
CurrentScreen generates a unique code for every checklist question.
CurrentScreen sends a create service request with the list of all questions to ServiceRequestService.
ServiceRequestService returns a successful response indicating that the checklist has been created.
Localisation of Checklist Questions
CurrentScreen sends a request to LOCAPI to create localisation for all checklist questions.
Each question is assigned a generated code, a user-entered message, and is associated with the hcm-checklist module.
LOCAPI processes the localisation request and returns a response.
Completion and Feedback
CurrentScreen displays a toast notification to the User indicating the successful creation of the checklist.
User is redirected back to the Checklist View screen, where they can see the newly created checklist.
Service Request Failures: If a service request fails at any point, the CurrentScreen will display an error message to the User. Users must resolve the issues and retry the operation.
Validation Errors: During checklist creation, if validation errors are detected, the CurrentScreen will notify the User with specific details, and the user must correct the issues before proceeding.
This documentation provides a comprehensive overview of the checklist management process within a campaign. The structured sequence ensures that all checklist-related activities are handled correctly, from viewing existing checklists to creating and localizing new ones. By adhering to this flow, users can manage checklists efficiently, ensuring consistency and accuracy in their campaign management activities.
The documentation details the API endpoints for creating, updating, and searching project type campaigns. It includes request and response structures, validation steps, and flow diagrams.
POST /project-type/create
RequestInfo: Object containing RequestInfo.
CampaignDetails: Object containing the details of the campaign to be created.
tenantId: Tenant identifier.
hierarchyType: Type of hierarchy.
action: Action type (create or draft).
boundaries: Array of boundaries.
resources: Array of resources.
projectType: Type of the project.
deliveryRules: Array of delivery rules.
Additional request info
ResponseInfo: Object containing ResponseInfo.
CampaignDetails: The created campaign details.
The client initiates a createCampaign request to the Project Factory Service.
If the action is 'create':
The Project Factory Service validates the request schema.
It also validates the uniqueness of the campaign name in the database.
If the campaign name exists, an error is thrown.
If the action is 'draft':
The Project Factory Service validates the request schema.
It also validates the uniqueness of the campaign name in the database.
If the campaign name exists, an error is thrown.
For both 'create' and 'draft' actions:
The Project Factory Service validates the request for hierarchy type and boundaries with the Boundary Service.
It validates the request for project type code from MDMS.
If the action is 'create':
The Project Factory Service validates the request for data resources.
It enriches the CampaignDetails and sets the status to 'creating'.
The CampaignDetails are persisted in the database.
For each resource data, the Project Factory Service creates resources through the /project-factory/v1/data/_create API.
It enriches boundaries for project creation and creates projects for each boundary with the Health Project Service.
The enriched CampaignDetails are persisted in the database.
The CampaignDetails object is sent to a Kafka topic for project mappings.
If the campaign status is not "created", project mappings are performed through the /project-factory/v1/project-type/createCampaign API and the status is updated to 'created'.
If the campaign status is already 'created', an error is thrown, and the status is updated to 'failed'.
If the action is 'draft':
The CampaignDetails are enriched, and the status is set to 'drafted;.
The enriched CampaignDetails are persisted in the database.
The Project Factory Service sends the response back to the client.
POST /project-type/update
RequestInfo: Object containing RequestInfo.
CampaignDetails: Object containing the details of the campaign to be updated.
id: Unique identifier of the campaign.
tenantId: Tenant identifier.
hierarchyType: Type of hierarchy.
action: Action type (create or draft).
boundaries: Array of boundaries.
resources: Array of resources.
projectType: Type of the project.
deliveryRules: Array of delivery rules.
ResponseInfo: Object containing ResponseInfo.
CampaignDetails: The updated campaign details.
The ProjectFactoryService receives an updateCampaign request from the Client.
The received request schema is validated to ensure it matches the expected format.
The system checks if the campaign specified in the request exists in the database.
If boundaries are different from campaign in db, call:
Facility template generate
User template generate
Target template generate
If delivery conditions are different, call:
Target template generate
If the campaign exists, the system checks its status in the database.
If the campaign status is 'drafted':
Validate Boundaries: Validate the request for hierarchyType and boundaries.
Validate Project Type: It validates the request for project type code from MDMS.
Enrich Campaign Details: Enrich the campaign details and set the status to 'updating'.
Update Campaign Details: Update the campaign details in the database.
Update Resource Data: Update each resource data associated with the campaign through the /project-factory/v1/data/_update API.
Enrich Boundaries: Enrich the boundaries for the project update.
Update Projects: Update projects associated with each boundary.
Persist Changes: Persist the updated campaign details in the database.
Send to Kafka Topic: Send the updated CampaignDetails object to the Kafka topic for project mappings.
Listen to Kafka: Listen for updates from the Kafka topic to get the updated CampaignDetails object for project mappings.
If the campaign status is not 'created':
Do project mapping through /project-factory/v1/project-type/createCampaign API.
Enrich the CampaignDetails and set the status to 'created'.
Update the CampaignDetail in the database.
If the campaign status is 'created':
Throw an error indicating that the project is already mapped for this campaign.
Enrich the CampaignDetails and set the status to 'failed'.
Update the CampaignDetail in the database.
If the campaign status is not 'drafted', the system throws an error indicating that only drafted campaigns can be updated.
The ProjectFactoryService sends a response to the Client based on the outcome of the update operation.
POST /project-type/search
RequestInfo: Object containing RequestInfo.
CampaignDetails: Object containing the search criteria for campaigns.
tenantId: Tenant identifier.
ids: Array of campaign IDs to search for.
startDate: The start date for the search.
endDate: End date for the search.
projectType: Type of the project.
campaignName: Name of the campaign.
status: Status of the campaign.
createdBy: Creator of the campaign.
campaignNumber: Number of the campaign.
campaignsIncludeDates: Flag to include campaigns based on dates.
pagination: Object containing pagination settings.
limit: Maximum number of results to return.
offset: Offset for paginated results.
sortOrder: Sort order for results (asc/desc).
sortBy: Field to sort results by.
ResponseInfo: Object containing ResponseInfo details.
CampaignDetails: Array containing details of matching campaigns.
totalCount: Total number of matching campaigns.
The client sends a searchCampaign request to the Project Factory Service.
The Project Factory Service validates the request schema and search criteria.
The Project Factory Service constructs a search query based on the provided criteria.
It checks if there are specific search fields like start date, end date, campaign name, etc.
Depending on the campaignsIncludeDates flag, the service adjusts the search conditions accordingly.
If campaignsIncludeDates is true:
It shows only those campaigns whose start date is on or before the provided start date and whose end date is on or after the provided end date.
If campaignsIncludeDates is false:
It shows only those campaigns whose start date is on or after the provided start date and whose end date is on or before the provided end date.
The service executes the constructed query to retrieve matching campaign details from the database.
The Project Factory Service sends the response back to the client.
The response contains the matching campaign details along with the total count, if applicable.
POST /project-type/getProcessTrack
campaignId: Unique ID of the campaign.
Success Response:
ResponseInfo: Object containing ResponseInfo details.
processTrack: Array containing process tracks of the matching campaign.
Client Initiates Request
The client sends a request to retrieve process tracks for a specific campaign by providing the campaignId.
Validation of Request
The Project Factory Service validates the provided campaignId to ensure it meets the expected format and constraints.
Fetch Process Tracks
The Project Factory Service constructs a query to fetch process tracks associated with the provided campaignId.
The service executes the query against the database to retrieve the process tracks.
Response
The Project Factory Service formats the retrieved process tracks and packages them into the response.
The response includes the ResponseInfo and an array of processTrack details.
Send Response to Client
The Project Factory Service sends the response back to the client containing the process track details for the specified campaign.
processTrackTypes (Steps)This defines various types of process tracks, each representing a specific stage or action in the campaign creation process. These types can be used to categorize and identify different steps or activities within the campaign workflow. Here's what each type represents:
validation: Represents the validation stage of the campaign creation process, where data or conditions are checked for correctness.
triggerResourceCreation: Indicates the step where resources are created based on triggers or conditions.
facilityCreation: Refers to the creation of facilities or resources required for the campaign.
staffCreation: Involves the creation of staff members necessary for the campaign.
targetAndDeliveryRulesCreation: Represents the creation of rules related to targets and delivery mechanisms (project creation step).
confirmingResourceCreation: Involves confirming that resources have been successfully created.
prepareResourceForMapping: The stage where resources are prepared for mapping to projects.
validateMappingResource: Represents the validation of resources after they have been mapped.
staffMapping: Involves mapping staff to projects.
resourceMapping: Represents the mapping of various resources to projects.
facilityMapping: Refers to mapping facilities to projects.
campaignCreation: Represents the creation of the campaign itself (final step).
error: Indicates that an error occurred during the campaign creation process.
processTrackStatusesThis object defines different statuses that a process track can have, reflecting the state or progress of a particular step in the campaign creation process. Here are the statuses and their meanings:
inprogress: Indicates that the process or task within the campaign creation process is currently ongoing and has not yet been completed.
completed: Represents that the process or task within the campaign creation process has been successfully finished.
toBeCompleted: Refers to processes or tasks within the campaign creation process that are scheduled or pending completion in the future.
failed: Signifies that the process or task within the campaign creation process encountered an error or failed to execute as intended.
This document outlines the various API flows and interactions for the Project Factory, focusing on resource data creation with retry logic, template generation, campaign update flows, and data search and download processes. The aim is to manage and automate various aspects of resource and campaign data efficiently using the Project Factory services.
Description: This flow describes how the Project Factory handles resource data creation with retry logic. It ensures data consistency and reliability by retrying operations if failures occur.
Sequence of Operations:
Client Request Initiation:
The client sends a request to the Project Factory with filestoreid and type.
MDMS Service Interaction:
Project Factory retrieves the type schema from the MDMS Service.
MDMS Service returns the schema, which is then validated.
Data Validation:
The Project Factory validates the data against the MDMS schema.
If validation is successful, it informs the client that data processing has started.
If validation fails, an error message is returned, and the user must resubmit.
File Handling:
The Project Factory requests a file download from the FileStore Service.
Upon receiving the file, JSON data is created from the file of the desired type.
Data Creation and Retry Logic:
Data is validated according to the schema.
Normal Create:
Data is created in the respective service, and status is tracked.
A loop continues until retry attempts exceed the maximum retries, or no failed data remains.
Bulk Create with Retry:
Data is created in the respective service, and the status is checked.
A search is conducted using the generateApi search.
The loop continues under the same conditions as the normal create process.
Database Update:
The file is enriched with the created ID and sent back to the FileStore Service.
The updated file is received, and data is persisted in the database with a status of 'created' and the processed filestoreid.
Description: This flow is triggered when a client sends a generate request with forceUpdate = true. It checks for existing data and creates a new row with the status inProgress if necessary.
Sequence of Operations:
Client Request Initiation:
The client sends a generate request with the specified type and forceUpdate = true.
Validation and Data Check:
The Project Factory validates the type against predefined types and hierarchytype.
A check is performed to see if previous data exists. If it does, the data is marked as expired.
Database and Response:
A new row is created with null fileStoreId and status inProgress.
The database is updated, and a success response is sent back to the client.
Data Fetch and Storage:
The Project Factory fetches the template from the MDMS Service based on the type.
Data is consolidated and stored in the FileStore Service, which returns a filestoreid.
The database is updated with the new filestoreid.
Description: This flow is initiated when a generate request is sent due to a boundary change in an ongoing campaign.
Sequence of Operations:
Boundary Change Trigger:
The Project Factory sends a generate request with campaignId, type, and forceUpdate = true.
Validation and Data Check:
The type is validated against predefined types and hierarchytype.
Previous data is checked, and if found, marked as expired.
The campaign is searched in the database based on the provided campaignId and its parent campaign ID.
Database and Response:
A new row is created with null fileStoreId and status inProgress.
The database is updated, and a response is provided.
File Update and Data Consolidation:
The Project Factory fetches file details from the FileStore Service using the parent campaign object.
The sheet is updated, freezing all the data.
If new boundaries are added, boundary relation data is fetched.
Data is consolidated, and stored in the FileStore, and the database is updated with the new filestoreid.
Description: This flow allows the client to search and download resource data based on a provided ID and type.
Sequence of Operations:
Client Request Initiation:
The client sends a request with the id and type.
Database Query:
The Project Factory checks the created resource based on the provided ID.
The corresponding resource details row is fetched from the database.
Response to Client:
The Project Factory sends back the created resource response to the client.
During Create flow
During Update Flow
The outlined API flows are crucial for handling resource data creation, management, and retrieval efficiently. They ensure data consistency, integrity, and seamless interaction between various services, making the Project Factory a robust system for managing campaign data. Implementing the retry logic, data validation, and template generation processes helps maintain a reliable and scalable architecture.
DIGIT 2.9 LTS
MDMS V2
mdms-v2-db:MDMS-v2-2.9LTS-fc6b868dce-47
new service
Boundary V2
boundary-service:boundary-hierarchy-def-modified-6d5b30d4f6-9
new service
HCM v1.4
project-factory:v0.1.0-6caaf2700e-6
new service
workbench-ui:v0.1.0-6caaf2700e-16
new service
The platform architecture illustration below provides a visual representation of the key components and layers that facilitate a campaign creation flow in health campaign management.
The following are the various master data that will be used during the campaign creation process.
Different types of campaign and delivery rules.
Attributes on which delivery rules can be created.
Schema to validate the Excel data for different templates.
Parsing and transforming templates.
Type to API mapping.
Configuration and devops details
Overview
This service is used to create a Project (Campaign), create required resource data, and create a mapping relation between them based on the boundary data.
Project
Facility
Product
HRMS
MDMS
Boundary
Localisation
Access Control
IdGen
Individual
User
Base Path: /project-factory/
API Contract Link
Table Details
Process Track api
This user manual is designed to serve as a comprehensive guide for system admins and programme managers responsible for managing and configuring various aspects of campaign data using the HCM Console. The manual covers a range of functionalities, from updating campaign data to configuring checklists and managing boundary data, ensuring that users can efficiently and effectively manage their campaigns.
User Role
Scope of Action
Role Description
System Admin
National Level/Provincial Level
The user will have all the data required for setting up a campaign and will be responsible for campaign setup on the DIGIT HCM app using the campaign data.
Dual Timeline View for Campaign Creation
Overview
The campaign creation process is structured with a dual timeline to manage different steps more effectively. The Horizontal Timeline at the top handles major campaign setup steps, while the Vertical Timeline on the left handles sub-steps within each major step. Horizontal Timeline
Step 1 - Campaign Details:
Step 1.1: Define campaign Type
Step 1.2: Define Campaign Name
Step 1.3: Define Campaign Dates
Step 1.4: Review a summary of the campaign details
Boundary Details:
Step 2.1: Select boundary data for the campaign. This step does not have a Vertical Timeline.
Delivery Details:
Step 3.1: Set up the number of cycles and deliveries, including the cycle dates.
Step 3.2: Set up rules for the delivery of resources.
Step 3.3: Review a summary of the delivery details.
Upload Data:
Step 4.1: Upload data for targets.
Step 4.2: Upload data for facilities.
Step 4.3: Upload data for the creation of HCM app users sections.
Step 4.4: Review a summary and success screen before proceeding to app configuration.
App Configuration:
Step 5.1: Manage checklists and other configurations for the HCM mobile app.
2. Configuring Checklists Based on User Roles
System admins can create and manage checklists for different roles within a campaign. Each checklist can contain specific questions tailored to the roles and checklist types defined by the campaign needs.
Step 1: Access Checklist Creation
Navigate to Checklist Creation:
Step 1: Once you have submitted the campaign data and started the campaign creation process, move to the app configuration section.
Step 2: On the vertical timeline, the Manage Checklist Creation step will appear as the first step.
Step 3: You will see a table with columns: Name of the Checklist, Role, Checklist Type, and Status.
Understanding the Table:
Checklist Name: Displays the name of the checklist.
Role: Shows the selected role for which the checklist is configured (e.g., National Supervisor, District Supervisor).
Checklist Type: Indicates the type of checklist selected for the given role.
Status: An "Active/Inactive" toggle determines whether the checklist is visible to the user on the HCM mobile app.
Step 2: Create New Checklist
Initiate New Checklist Creation:
Click on Add New Checklist on the top-right corner of the screen.
A pop-up window will appear, prompting you to select the role and checklist type.
Select Role and Checklist Type:
From the dropdown menu, select the appropriate role for which the checklist is being created (e.g., National Supervisor, District Warehouse Manager).
Select the checklist type from the dropdown menu, which will list all applicable checklist types for the selected role.
Close or Create Checklist:
After making your selections, click Create Checklist to proceed. If you miss selecting either the role or checklist type, an error message will appear.
Step 3: Add Questions and Answers
Add Checklist Name:
Once the role and checklist type are selected, you must assign a unique name to your checklist. This name must be unique within the role.
Add Questions:
Click on Add New Question to start creating questions.
A section labeled "Question 1" will appear, with a text box below it for entering the question.
Select Answer Type:
- Select the answer type from the dropdown menu. The options include:
Multiple Choice (Single Select): App users can select only one answer from a list of options.
Multiselect (Checkboxes): App users can select multiple answers from a list of options.
Dropdown (Single Select): App users can select a single answer from a dropdown menu.
Short Answer: Allows app users to enter a text-based response.
Configure Options for Multiple Choice/Dropdown:
If you selected Multiple Choice or Dropdown as the answer type, you will need to configure the available options.
Click on Add New Option to add more choices. Each option can be edited, and up to 10 options can be added.
Add Comments or Linked Questions:
For Multiple Choice and Dropdown types, you can enable the "Add Comment" option, allowing users to provide additional text when selecting certain answers.
Alternatively, you can create linked (nested) questions that will appear based on the user's answer. This can be nested up to 5 levels.
Delete Questions or Answers:
To delete a question or answer, click the delete icon next to it. Be sure to review all entries before proceeding.
Step 4: Preview and Create Checklist
Review Questions and Answers:
Once all questions and answers are added, review them to ensure accuracy.
Click on the Preview button in the top-right corner to see how the checklist will appear in the HCM Mobile App.
Create the Checklist:
If everything is correct, click the Create Checklist button to finalize the checklist.
A success screen will appear for 5 seconds before redirecting you to the Checklist home screen.
Step 5: Manage Drafts and Active Checklists
Saving Checklists as Draft:
If you navigate away or close the screen without creating the checklist, it will be saved as a draft (assuming a unique name was provided).
Activate or Inactivate Checklists:
Use the "Active/Inactive" toggle on the Checklist home screen to control whether a checklist is available to users in the HCM mobile app.
Managing Boundary Data
Programme managers can manage boundary data for specific campaigns. Boundaries can be created, edited, and managed using data from GeoPoDe or through custom ShapeFiles and Excel uploads.
Steps for Managing Boundary Data Using GeoPoDe:
Step 1: Access Boundary Management:
Log in to the HCM Console.
Navigate to the Boundary Management section from the main dashboard.
On the Boundary Management home screen, click the Create New Boundary Data button.
Step 2: Choose Boundary Data Source:
A prompt will ask if you want to use GeoPoDe data or create your boundary data.
If you select Get Boundary Data From GeoPoDe, the system will fetch the available boundary hierarchy and data for your country.
Step 3: Handle Partial Boundary Data:
If only partial boundary data is available from GeoPoDe, the missing levels will need to be created manually.
Add the missing boundary hierarchy levels using the Add Boundary Hierarchy Level button.
Step 4: Upload Additional Data:
For missing boundary levels, you can upload data via ShapeFiles or Excel.
Download the Excel template if needed, fill in the missing boundary data, and upload it back into the system.
Step 5: Preview and Confirm Boundary Data:
Once all data is uploaded, preview the boundary data on a map or in an Excel format.
Use the filters to view different boundary levels or base maps (e.g., Satellite, Street Map).
Click the Confirm Boundary Data button to finalize the boundary data. A success screen will appear for 5 seconds before redirecting you to the Boundary Management home screen.
Steps for Creating Custom Boundary Data:
Step 1: Create Custom Boundary Hierarchy:
If GeoPoDe data is not used, click Create My Own Boundary Data.
Add new boundary hierarchy levels using the Add New Boundary Hierarchy button.
Name each level, and add up to 10 levels as needed.
Step 2: Add Custom Boundary Data:
Upload boundary data using either ShapeFiles or Excel.
If using ShapeFiles for some levels and Excel for others, download the Excel template to ensure consistency.
Fill in the boundary data for the levels not covered by ShapeFiles and upload the completed Excel file.
Step 3: Preview and Confirm Custom Boundary Data:
Preview the boundary data on a map or in Excel format.
Use the filters to view different boundary levels or base maps.
Click Confirm Boundary Data to finalize the boundary data.
Steps for Editing Existing Boundary Data:
Step 1: Access Existing Boundaries:
Step 1: In the Boundary Management home screen, click View Existing Boundary Data.
Step 2: A table will display all existing boundaries with details such as Disease Type, Last Campaign Usage, and Creation Date.
Step 2: Edit Boundary Data:
To edit boundary data at the lowest level of the hierarchy, download the relevant ShapeFile or Excel.
Step 3: Modify the data as needed:
Add New Boundaries: Set the boundary status to 'Active' for new boundaries.
Remove Boundaries: Set the boundary status to 'Inactive' for boundaries to be removed.
Combine or Split Boundaries: Update the ShapeFile or Excel to reflect combined or split boundaries.
Step 4: Upload Edited Data:
Save and upload the modified ShapeFile or Excel back into the system.
Preview the updated boundary data and confirm the changes.
Note: Changes to boundary data will only apply to future campaigns. Ongoing campaigns will continue to use the boundary data with which they were created.
Editing Campaign Data
System admins can manage and update campaign data, such as Targets, Facilities, and Users, during an ongoing or upcoming campaign. This feature reduces the dependency on the Implementation Team and enables quicker adjustments.
Before editing campaign data, ensure that:
You have access to the HCM Console.
The campaign is either in an upcoming or ongoing state.
You have the latest uploaded files for Target, Facility, and User data.
Detailed Steps to Select New Boundaries:
Access the Campaign:
Log in to the HCM Console.
Navigate to the My Campaigns section from the main dashboard.
Locate and select the campaign you wish to update. This will take you to the campaign summary screen.
Edit Boundaries:
On the My Campaign screen, click the Actions button and then select Edit Campaign Boundary Data from the dropdown.
The user will then be taken to the boundary selection screen where they can only add existing boundaries from the dropdown.
Mandatory Data Updates:
After selecting new boundaries, click Submit.
The system will automatically redirect you to the Target, Facility, and User data update screens. These updates are mandatory to ensure consistency in campaign data.
Complete the necessary updates in each of the Target, Facility, and User data screens.
Detailed Steps to Edit Target Data:
Access the Campaign:
Navigate to My Campaigns in the HCM Console.
Select the campaign for which you want to edit target data.
Edit Target Data:
On the Update Target Data Screen, click on the "Download Existing Data" button to download the last successfully uploaded file used for creating the Target Data.
Open the downloaded file and review the existing Target data.
Download and Edit Target Data:
On the Target Upload Screen, note that the "Download Template" button is disabled. Instead, download the last successfully uploaded file that was used to create the Target Data for the campaign.
Open the downloaded file and review the existing data.
Edit Data When New Boundaries Are Added:
On the Update Facility Data Screen, click on the "Download Existing Data" button to download the last successfully uploaded file used for creating the Facility Data.
Open the downloaded file and review the existing facility data.
Upload Updated Data:
After making the necessary edits, save the Excel file.
Return to the Target Upload Screen and upload the updated Excel file.
Ensure that the upload is successful and the changes are reflected in the campaign summary.
Detailed Steps to Edit Facility Data:
Access the Campaign:
Go to My Campaigns in the HCM Console.
Under My Campaigns go to the campaign for which you want to edit Facility Data and under “Actions” click on “Edit Facility Data”.
Download and Edit Facility Data:
On the Update Facility Data Screen, click on the "Download Existing Data" button to download the last successfully uploaded file used for creating the Facility Data.
Open the downloaded file and review the existing facility data.
Edit Data When New Boundaries Are Added:
If new boundaries are added to the campaign, these will be appended to the “List of Campaign Boundary” sheet.
Review and update the facility status, boundary mapping, and create any new facilities as needed. Note: Removal of existing boundary data is not allowed.
Upload Updated Data:
After making the necessary edits, save the Excel file.
Return to the Facility Data Upload Screen and upload the updated Excel file.
Ensure that the upload is successful and that the changes are reflected in the campaign summary.
Note on Deactivation/Deletion:
If there are facilities that need to be deactivated or deleted, contact the Impel Team as this action requires additional checks and cannot be performed through the Console.
Detailed Steps to Edit User Data:
Access the Campaign:
Go to My Campaigns in the HCM Console.
Select the “Actions” button for that specific campaign and in the dropdown that opens, select “Edit App User Data”.
Download and Edit User Data:
On the Update App User Data Screen, click on the "Download Existing Data" button to download the last successfully uploaded file used for creating the App User Data.
Open the downloaded file and review the existing App User data.
Edit Data When New Boundaries Are Added:
If new boundaries are added to the campaign, these will be appended to the “List of Campaign Boundary” sheet.
Review and update user roles, boundary mapping, and create any new users as needed. Note: If a user is assigned to a boundary that has been deselected, update the boundary mapping for that user.
Upload Updated Data:
After making the necessary edits, save the Excel file.
Return to the User Data Upload Screen and upload the updated Excel file.
Ensure that the upload is successful and that the changes are reflected in the campaign summary.
Note on Deactivation/Deletion:
If the users need to be deactivated or deleted, contact the impel team as this action requires additional checks and cannot be performed through the Console.
Note: You can access the templates for data upload below:
Boundary Bulk Upload Overview:
This documentation outlines the process and components of bulk uploading boundaries for a campaign. It covers the proper format of the Excel sheet, unique code generation, functions for boundary entity creation, boundary relationship creation, localisation, and API details.
The Excel sheet should be formatted as follows:
Unique codes are auto-generated for each boundary level as follows:
If there are two districts (boundaries at the same level) with the same name (for example, BLR) under different parent-level boundary, the names will be updated to BLR, BLR-01, and so on.
Purpose:
Generate auto-generated boundary codes based on boundary list, child-parent mapping, element codes map, count map, and request information.
Parameters:
boundaryList: List of boundary data.
childParentMap: Map of child-parent relationships.
elementCodesMap: Map of boundaries to its corresponding auto generated unique codes.
countMap: Map of counts for each boundaries.
request: HTTP request object.
Returns:
Updated element codes map.
Steps:
Initialise Column Data:
Initialise an array to store column data.
Extract Unique Elements:
Iterate through each row of the boundary list.
Extract unique elements from each column.
Generate Boundary Codes:
Iterate over columns to generate boundary codes.
Check if the element code exists in the element codes map.
If not, generate a new code based on parent-child mapping and sequence.
Store the code of the element in the element codes map.
Default Code Generation:
Generate default code if parent code is not found.
Updated Element Codes Map
Return Updated Boundary Data - Auto-Generated Code Map.
Boundary entities are created chunk-wise, with each chunk consisting of 200 codes.
Purpose:
To create new boundary entities in the system from provided boundary codes.
Steps:
Convert Boundary Map:
Change the boundary map to a list of objects with key and value.
Prepare Request:
Set up the request details and initialise lists for boundaries and existing codes.
Chunk Boundary Codes:
Divide the boundary codes into smaller groups.
Fetch Existing Boundaries:
Check the system for existing boundary codes and collect them.
Identify New Boundaries:
Determine which boundary codes are new and add them to the list of boundaries to create.
Create New Boundaries:
If there are new boundaries, send them to the system in groups and log the results.
Handle Existing Boundaries:
Log a message if all boundaries already exist.
Error Handling:
Manage any errors that occur and provide a relevant error message.
Create Boundary Relationship Purpose:
To create boundary relationships in the system from provided boundary codes and their parent-child mappings.
Steps:
Convert Boundary Map:
Transform the boundary map to a list of {key, value} objects.
Initialise Request:
Prepare the request details and activity messages array.
Fetch Existing Relationships:
Retrieve existing boundary relationships and extract their codes.
Identify and Create Relationships:
For each boundary code, check if it exists. If not:
Prepare the boundary relationship data.
Confirm the parent boundary creation.
Create the boundary relationship.
Handle Existing Relationships:
If all relationships already exist, log a validation error.
Attach Activity Messages:
Add activity messages to the request body.
Error Handling:
Catch, log, and handle errors appropriately.
Boundary codes are localised to their corresponding names as specified in the uploaded Excel sheet.
To add more boundaries after the initial upload, use an Excel sheet that includes existing boundary codes. New boundaries without codes will be created in the same way as the first upload.
API request for boundary bulk upload:
Note: Ensure the API endpoint, headers, and payload are customised as per your environment and requirements.
Here are the articles in this section:
This allows users to fill in all the campaign details and create a new campaign.
Click on the following links to learn more:
Generate API for Boundary with Latitude and Longitude
Generation API for Boundary
Base URL: project-factory/v1/
Endpoint: /data/_generate
Method: POST
Request Structure:
Body Parameters:
RequestInfo: Object containing RequestInfo
Query Parameters:
tenantId: Tenant
type: Type of Resource (e.g., boundaryManagement)
forceUpdate: Boolean type (either true or false)
hierarchyType: Name of Boundary Hierarchy
campaignId: default (Mandatory)
Response Structure:
Success Response:
Client Initiates Request:
The client initiates a dataGenerate request to the Project Factory Service.
Validation of Request:
Schema Validation: Validate against generateRequestSchema.
Tenant ID Validation: Ensure tenantId matches in query and RequestInfo.userInfo.
Force Update: Default to "false" if missing.
Hierarchy Type Validation: Validate hierarchyType for the tenantId.
Processing of Generate Request:
Fetch Data from DB:
Retrieve data using getResponseFromDb(request).
Modify Response Data:
Modify the fetched data with getModifiedResponse(responseData).
Generate New Entry:
Create a new entry with getNewEntryResponse(request).
Expire Old Data:
Update the status of old data to expired using getOldEntryResponse(modifiedResponse, request).
Persist Data Changes:
Call updateAndPersistGenerateRequest(newEntryResponse, oldEntryResponse, responseData, request).
Purpose:
If forceUpdate is true and data exists: Mark existing data as expired and create new data.
No data exists or force update is true: Generate new data.
If forceUpdate is false and data exists: Return the old data.
Boundary Data Processing:
Generate new Boundary Data:
Fetch Boundary Relationships.
If no boundary is found, generate an empty boundary sheet.
Fetch Filters from CampaignId and generate Boundary Data based on those Filters.
If Filters is null, it will generate the whole Boundary Data.
After the Boundary Sheet has been generated, append the ReadMeSheet.
Generate different tabs based on any boundary level configured (here District).
Generating Different Boundary Templates based on Campaign Type
Fetch configurable columns from mdms present for each campaign type from schema -[HCM-ADMIN-CONSOLE.adminSchema].
Here is a sample data from the given schema having configurable columns for Campaign SMC-
Handle Error:
Update status to failed, add error details, log the error, and produce a message to the update topic.
Downloading the generated boundary template through /data/_generate API:
One can get the filestoreId through the /data/_download API which will fetch from db using the id from the response of /data/_generate API.
Note:
Downloaded Template will have one ReadMe sheet, one Boundary Data Tab, and all other tabs on a number of unique districts(or whichever level configured).
UI/UX audit done, and feedbacks incorporated
Verify whether all docs will be published to by the Technical Writer as part of the release.
,
HCM Admin Console Incremental Handover Date: May 16 Date: Jun 21
/
Campaign Create
Campaign Update
Manage Resources
INDIA
INDIA
KARNATAKA
INDIA
KARNATAKA
BLR
INDIA
KARNATAKA
BLR
KORAMANGALA
INDIA
KARNATAKA
BLR
KORAMANGALA
3RD BLOCK
INDIA
KARNATAKA
BLR
KORAMANGALA
3RD BLOCK
EGOV
INDIA
BIHAR
INDIA
BIHAR
PATNA
INDIA
ADMIN_IN
KARNATAKA
ADMIN_IN_01_KARNATAKA
BLR
ADMIN_IN_01_01_BLR
KORAMANGALA
ADMIN_IN_01_01_01_KORMANGALA
BIHAR
ADMIN_IN_02_BIHAR
PATNA
ADMIN_IN_02_01_PATNA
The logic for the step-by-step screens, stepper functionality, storing data in localStorage, creating/updating campaigns, and restructuring API data back into localStorage is all managed within SetupCampaign.js.
All screens are present in the given configuration. Link: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/configs/CampaignConfig.js
In the configuration:
stepCount represents the step number. Multiple configuration objects can share the same stepCount.
skipAPICall: If this is set to true, the API call for the screen is skipped.
sessionData: Local storage data is passed in custom props, allowing for custom logic to be added to the screens as needed.
In setup campaign, we have functions to perform specific logic:
loopAndReturn: This function takes the delivery rule conditions coming from API response and restructure the data in local storage format.
cycleDataRemap: This function takes the delivery rules data coming from API response and return array of object of start date and end date based on cycles.
reverseDeliveryRemap: This function takes the deliveryConditions from the API response and return the structure of delivery data.
groupByTypeRemap: This function creates the local structure of boundaries.
updateUrlParams: This function is used to update the URL.
In a new campaign, we update the total form when a user clicks on next after entering the data.
After updating the total form data, we store the data in localStorage.
We also call the API to draft the data in case a user wants to come back and resume the campaign.
Refer to the following link:
When a user clicks on the draft campaign, he/she can fetch campaign data from the response.
After getting a response, one can restructure the data in screen format and store it in the local storage.
After updating, the user is redirected to the last screen where additional details are stored in response.
Refer to the following link:
Based on screens, a user can filter the configuration and show the stepper based on the configuration.
Refer to the following link:
As part of v0.3, we have introduced a new vertical stepper and summary screens for all the steps.
The vertical steppers are clickable and the user can navigate between the screens using the steppers.
Summary screens will show all the details entered by the user in that step.
Click here to learn more.
The "Setup Campaign" feature facilitates the creation of a campaign using an approved microplan. It ensures that only authorized users can initiate the setup process, generates required campaign data, and integrates with external APIs to fetch user, facility, and target data.
Role Required: MICROPLAN_CAMPAIGN_INTEGRATOR
Validation Logic:
Only users with the above role can select an approved microplan to initiate the campaign setup.
If the user lacks the role, access to the feature is denied with a proper error message.
Input: Approved microplan object.
Steps:
Extract the base campaign object from the selected microplan.
Create a new campaign object by cloning the base campaign object with the following updates:
Add unique identifiers (campaignId, createdBy).
Set the campaign status to draft.
Save the new campaign object to the backend.
Trigger: After updating the campaign object with selected boundaries, it gets auto-generated from Backend
Steps:
Automatically generate empty templates for the campaign, including:
User assignments.
Facility data placeholders.
Target data placeholders.
API Endpoint: project-factory/v1/project-type/fetch-from-microplan
Steps:
Call the Microplan API to fetch:
User data.
Facility data.
Target data.
Populate the empty templates with the fetched data.
Save the updated templates back to the backend.
Purpose: Monitor the progress of data population and transition to the next step once completed.
Steps:
The UI triggers a periodic call to the campaignSearch endpoint:
API Endpoint: /campaign-search
Parameters: campaignId.
Check the status of the campaign:
If Completed:
Navigate the user to the Setup Campaign page.
If In Progress:
Re-trigger the data fetch from Microplan API to ensure completion.
Continue polling.
Steps:
Transition the user to the Setup Campaign page.
Pass the necessary campaign data as route parameters or via state management.
project-factory/v1/project-type/fetch-from-microplan
MICROPLAN_CAMPAIGN_INTEGRATOR
project-factory/v1/project-type/search
CAMPAIGN_MANAGER
project-factory/v1/project-type/create
CAMPAIGN_MANAGER
project-factory/v1/project-type/update
CAMPAIGN_MANAGER
project-factory/v1/data/_download
CAMPAIGN_MANAGER
The document is a guide to the various configuration options available in the HCM Console. Proper configuration is crucial for optimising performance, ensuring security, and customising the user experience to meet specific needs. This document is designed to help system administrators, developers, and end-users understand and implement these configurations effectively. To learn more about HCM Service/App Configuration, Click here.
This guide covers all aspects of application configuration, including global settings, module-specific options, and environment-specific adjustments. It addresses configuration methods such as through files, environment variables, and command-line arguments. Additionally, it includes advanced configuration topics like custom scripting, API integrations, and feature flag management.
The primary audience for this document includes:
System Administrators: Responsible for setting up and maintaining the application in various environments.
Developers: Need to understand configuration options for development, testing, and deployment.
End-Users: They may require guidance on configuring user-specific settings via the user interface.
The document is organised into the following sections:
Configuration Types: Detailed descriptions of global, module-specific, and environment-specific settings.
Configuration Methods: Instructions on how to apply configurations using different methods.
Common Configuration Options: Examples of frequently used settings, including database connections, authentication, logging, and UI adjustments.
Advanced Configurations: Information on extending the application's functionality through custom scripts, plugins, and integrations.
Best Practices: Recommendations for managing configurations securely and efficiently.
Troubleshooting: Solutions to common configuration problems and tips for debugging issues.
Appendices: Additional resources, including a glossary and references for further reading.
By following the guidance provided in this document, users can ensure that the application is configured correctly to meet their operational needs, enhancing both performance and user satisfaction.
This overview section sets the stage for the rest of the document by clearly outlining its purpose, scope, intended audience, and overall structure.
The Boundary serves as the primary master data for a campaign and can be configured using the screen provided below. To upload a boundary into the database, a hierarchy is required. If the necessary hierarchy is not available in the existing list, it can be created using the designated screen. Hierarchies of any level can be established.
An example of a hierarchy structure is as follows, with the hierarchy type set to ADMIN:
First, navigate to the MDMS data configuration page with moduleName = HCM-ADMIN-CONSOLE and masterName = HierarchySchema and configure the console and campaign as the hierarchy you want to have (Ex. HierarchyTest22)
Keep hierarchy, lowest level, and split boundaries on column same for console and campaign and name should be same as defined while creating hierarchy. (Example: Here we have AdministrativePost and Locality)
Now navigate to the boundary management page and continue with boundary creation.
After creating the hierarchy we can download the template and add data to it.
In this screen, the user needs to download the template containing boundary levels in the headers according to the hierarchy. The user needs to fill that template in a specific format. A dummy template is attached for reference.
All the boundaries are localised to the below localisation module:
The system automatically generates a default localization for all boundary codes during the boundary data upload, using the same language/locale as specified at the time of upload.
The data provided above is based on the hierarchy created above. Any changes in the levels will change the headers respectively and data will have to be filled accordingly.
This schema contains different hierarchy types and their lowest hierarchy.
Based on isActive, choose which type of hierarchy the campaign will be created. This config defines the boundary hierarchy on which a campaign can be created. All the boundary levels are coming according to the hierarchy configured.
The lowestHierarchy will represent the lowest level hierarchy to be displayed in the boundary selection screen while creating a campaign.
The SplitBoundariesOn defines the hierarchy level for dividing the target sheet tabs.
The consolidateUsersAt the function is utilised during microplan integration, ensuring user sheets are populated
Users can change the lowest hierarchy but it is advised to keep till the mentioned level because a lot of boundaries will increase the validations and the load on the server to load all the boundaries
Based on this schema, validations happen in Excel from both the UI and the backend for the different uploads; there is one schema with the title according to the uploaded type. If a user wants to change anything in the Excel validation, then the data of the schema needs to be updated.
Schema properties:
IsRequired: True for all those columns that are mandatory to be filled
orderNumber: Position where that column will be present
title: Set according to the type of upload
enum: Defines a set of allowed values for a specific property, ensuring that only predefined, valid options can be assigned to that property.
numberProperties: Numeric fields with specific characteristics such as uniqueness, required status, and value constraints like minimum and maximum limits.
string properties: Text fields with specific characteristics such as required status, uniqueness, and constraints on length and content.
Users can change the following validations from Excel using this schema such as:
User Validations -
Roles - Roles to be validated can be added or deleted in the schema.
Employment Type - This can be changed from the enum.
All the headers are mandatory they can be adjusted according to the requirement, just by changing isRequired to true/false.
Facility Validations -
Facility Type - More types can be added or deleted.
Facility Status - More requirements can be added or deleted.
Facility Usage - More requirements can be added or deleted.
Capacity - Minimum and maximum can be changed.
Facility Name - Maximum length and minimum length can be changed.
All the headers are mandatory they can be adjusted according to the requirement, just by changing isRequired to true/false.
Target Validation -
Target - Minimum and maximum validations can be changed.
Boundary code and target header are mandatory.
It also has a field called campaign type, so based on the campaign type boundary target updated, any new target column can be introduced.
while introducing a new campaign/project type this admin schema needs to be added for that type.
It includes a list of attribute configurations, each identified by a unique key and specified by a code and an internationalisation key (i18nKey). The attributes listed are 'Age', 'Height', 'Weight', and 'Gender', which can be used in campaigns to capture relevant information.
The attribute dropdown is populated from this schema. If the user wants to add or delete attribute options, this schema is helpful.
This schema configures the base time interval after which the search API is called following a file upload. The search API checks the validation status of the uploaded file. The frequency of the API calls is determined by the data present, with the time interval calculated as the base time multiplied by the number of fields in the sheet, constrained by both the minimum base time and the maxTime stated in the schema. The search API will continue to be called repeatedly until a successful or failed response is received. TimelineRefetch is also added to call the getProcessAPI of the timeline after a certain interval of time.
Advised not to change the base time and max time to prevent delay in validation progress.
This is used in the delivery config schema to show the direct and indirect deliveries.
It has the by default mail ID to contact the L1 or implementation team if the hierarchy a user wants is not present. The mail ID can be configured from this schema
This schema contains all the operator options which are required for the attributes.
This schema displays the options to add the resource type if the resource a user wants is not present in the options. The resource added here will be present in the resources dropdown, so prevent adding any junk data.
This schema is used to display the info message in the UI and the read-me sheet in the downloaded template. It configures according to the upload type which shows the instructions to a user on how to fill the template. These codes are localised according to the message.
Below is an example of how data is entered into the read-me schema for the headers and their description:
type: defined the type of upload.
header: The text identifier for the header.
isHeaderBold: A boolean indicating whether the header text should be displayed in bold.
inSheet: A boolean indicating whether this header should be included in the sheet.
inUiInfo: A boolean indicating whether this header should be displayed in the UI.
text: The text identifier for the description.
isStepRequired: A boolean indicating whether this description step is required.
All the headers and descriptions are written in codes that are localised using the localisation module named:
To show the privacy policy component on the login page, a user needs to include the configurations in the MDMS:
Master Name: commonUiConfig
ModuleName: LoginConfig
In this user can customize(add/delete) the fields according to the requirement.
For more details, you can refer here.
This configuration displays the data in the privacy pop-up. An example of the configuration is shown below:
In the schema:
Type can be the following:
null:
When type is null, it indicates that the description is just plain text.
point:
When type is set to point, it likely means that the description should be displayed as a bullet point or list item.
step:
When type is set to step, it suggests that the description is part of a sequence of steps.
subdescriptions: to show the sub-descriptions in the point.
This config is used when we want to update the dates with or without the selected boundaries.
If the flag is false, then by default it updates the dates at the country level. If the user wants to update the dates at the lower boundary levels, then make the flag true.
This configuration is now used in the place of delivery configuration.
This is used to store all the pre-required conditions for the delivery conditions screens.
Master Name: HCM-PROJECT-TYPES
ModuleName: projectTypes
This is the sample data for the project type - MR-DN
Explanation for the MDMS Data
Project Types: Three main project types (LLIN-mz, MR-DN, and IRS-mz) with unique configurations.
Cycles and Deliveries:
Each project type contains cycles, and each cycle contains multiple deliveries.
Deliveries include details such as deliveryStrategy, doseCriteria, and ProductVariants.
Resources: A list of resources specific to each project type.
Eligibility Criteria: Contains a list of conditions for each project type.
Other Configurations:
attrAddDisable, deliveryAddDisable, and similar attributes determine UI behavior.
Requirements
Mandatory to set product variant ID according to the environment.
This Master data is used to show the dropdown of roles in the checklist screens
This Master data is used to default template of checklist for selcted campaign + role + checklist type
This is used to describe the type of questions available in the dropdown while configuring the checklist.
This schema is used by replacing hierarchyConfig schema.
The Console is being referred to for campaign creation. The campaign is being referred for boundary management.
This Master is utilized for Microplan Data fetching. Here, "type" refers to the data template that needs to be filled. "To" and "from" pertain to Microplan data, and while populating campaign data, various filter conditions, such as "includes" or "equals," can be applied.
HierarchySchema hierarchy schema is used now.
It was replaced by projectTypes to maintain the consistency between the health product app and console.
Refer here to learn more about the Helm Configurations
In the 'Delivery Details' step, users encounter 3 screens:
Cycles & Deliveries
Delivery Screen
Summary
On this screen, users specify the number of cycles and deliveries. The number of cycles must be at least 1 and can be up to 5. Once the user has defined the number of cycles and deliveries, they can proceed to enter the start and end dates for each cycle.
The number of cycles and deliveries are configurable based on project type. We can configure it in MDMS:
Link:
https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/health/project-types.json
If data is configured, a user will see the number of cycles and deliveries as per the configuration. A user, however, can increase or decrease if they find it necessary.
The validations added for the start date and the end date of the cycles should not overlap to each other.
After filling in all the cycle details, a user can click on 'Next' and move to the delivery rules screen. Clicking on 'Next' enables a user to store the cycle data in the local storage.
On this screen, users fill in all the delivery details (adding delivery rules, adding conditions in delivery rules, adding products in the delivery rules) of each cycle and delivery that the user has selected in the cycle details screen.
The delivery screen can also be configured based on project type. A user can configure the number of delivery conditions, their attributes, and products. If the data is configured correctly, a user can see the data preloaded in delivery rules and the user can change, remove, or add, if they find it necessary.
A user can add delivery rules up to 5. A user can add conditions in each delivery rule with attribute options having height, weight, gender, and age. For Project type, LLIN-mz configuration is passed in delivery rules in which two fixed attributes are present for the bednet campaign.
After filling in all the delivery rules details, when a user clicks on next, the data will be stored in the localStorage as well as in the draft API. The delivery rules data will be validated in the preview screen.
Reference files:
Delivery rule's screen file path: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/deliveryRule/index.js
API call file path: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/pages/employee/SetupCampaign.js
If you click on configure resources on the delivery screen, a pop-up appears where a user can either select or create a product:
Product Screen: When a user clicks on "Add Products to be Delivered", a pop-up screen will appear with a list of product variants where a user can add the products and the number of counts in the delivery rules.
A user can add multiple products to the product screen after clicking on "add more resources" When the user clicks on confirm resources, products will be added to the delivery rules. The user can remove the products as well.
If the product is not present, a user can click on "Add New Product" to create a new product and variant, and subsequently add delivery rules. Clicking on "Add New Product" will open the Create Product screen.
Users can enter product names, product variants, and product types which are sourced from MDMS data. Additionally, a user can create multiple products using the "Add Products" button. After clicking on 'Confirm,' the product will be created, followed by the creation of product variants.
After successful creation, users will be directed to a success response screen.
This screen will show the values the user has added in the cycle configuration screen and delivery screen.
Here you can find the config of delivery based on project type and the same acts as the default template.
This MDMS schema is used to fetch the details for every product type, to convert the data to the required format used by the screen, we are writing the util.
The following is the structure for the delivery configuration:
projectType: This will be the type of the project. If the selected project type is present in the MDMS, then we use that config.
attrAddDisable: if this is true, we are restricting a user that they cannot add any attribute.
deliveryAddDisable: if this is true, a user cannot add any further delivery rule conditions.
cycleConfig: This will be an object containing cycles and deliveries. This refers to the number of cycles and deliveries that will be shown on the cycle screen.
deliveryConfig: This will be an array of objects, each object representing one delivery condition.
Adding product config is a careful job, adding the wrong product in the config will cause issues while creating a product.
In Value, the product variant ID should be added in the value which will be getting in the below API:product/variant/v1/_search
The name will consist of the name of the product and the variant of the product separated with "-"
for name: product/v1/_search
for variant: product/variant/v1/_search
FilePath:
MDMS:
Product Type: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/hcm-admin-console/productType.json
HOOKS:
We have added the Delivery type at each delivery condition showing the delivery type of the campaign.
It is configurable in mdms for the SMC project type. We can add a default delivery type for each condition.
deliveryConfig: It will contain the default data of all deliveries.
conditionConfig: It will contain default data of each delivery condition of each delivery.
deliveryType: Default value of delivery type.
product/variant/v1/_search
CAMPAIGN_MANAGER
product/v1/_search
CAMPAIGN_MANAGER
product/v1/_create
CAMPAIGN_MANAGER
product/variant/v1/_create
CAMPAIGN_MANAGER
project-factory/v1/project-type/update
CAMPAIGN_MANAGER
My campaign screen allows users to see the list of campaigns that are in Ongoing, Completed, or Draft status. Users can search campaign by using the campaign name or campaign type. Users can also see a summary of the campaign and complete the campaign creation if it is draft status.
The list of statuses showing in the "My Campaign" screen are:
Ongoing
Completed
Drafts
Failed
Upcoming
After clicking on the My Campaign link from the HCM Campaign module card, the user lands on the My Campaign screen where the user can see all the lists of campaigns of each action in the tab.
On my campaign screen, we are sending the payload:
Campaigns with an end date that has passed the current date are marked as 'Completed'.
Campaigns with a status of 'Started' and no end date, or with an end date in the future, are labeled as 'Ongoing'."
The logic is written in UICustomizations.js
Clicking on campaigns other than draft status will redirect to the summary page of the campaign where the user can see the complete details of the respective campaign.
For the ongoing campaign filtering functionality, we are utilizing the campaignsIncludeDates parameter set to true. The startDate and endDate parameters are both set to the current date. This configuration ensures that the API will return any campaign where the specified startDate or endDate falls within the campaign's defined start and end dates. Additionally, the campaign status is filtered to include campaigns with statuses of created or creating.
campaignsIncludeDates: This boolean parameter is set to true to enable date range filtering.
startDate: The start date for the filter, is set to today's date.
endDate: The end date for the filter, is also set to today's date.
status: The campaign status filter, including the statuses created and creating.
To filter the ongoing campaigns based on the criteria mentioned above, ensure that your request payload includes the following parameters:
campaignsIncludeDates = true: This activates the date range filtering feature.
startDate and endDate = today: By setting both the start and end dates to today's date, the filter will capture any campaigns that are active today.
status = ["created", "creating"]: Filters the campaigns to only include those that are currently in the created or creating status.
For filtering completed campaigns, we use a similar approach with a slight modification to the date parameters and status. Specifically, we will set the endDate parameter to yesterday's date. This configuration ensures that the API returns campaigns that have ended as of yesterday. The statuses to filter will remain creating and created.
endDate: The end date for the filter, is set to yesterday's date.
status: The campaign status filter, including the statuses creating and created.
To filter the ongoing campaigns based on the criteria mentioned above, ensure that your request payload includes the following parameters:
endDate = yesterday: By setting the end date to yesterday's date, the filter will capture any campaigns that have ended by the end of the previous day.
status = ["created", "creating"]: Filters the campaigns to include only those that were in the created or creating status when they ended.
When a user clicks on the completed campaign, they will be redirected to the summary page displaying the campaign details. The success toast message will appear If the user credential sheet is generated successfully. Users can view or download the sheet from the user credential card or download button which appears at the top.
For filtering upcoming campaigns, we use a different approach by setting the campaignsIncludeDates parameter to false and specifying the startDate parameter to tomorrow's date in epoch format. This configuration ensures that the API returns campaigns scheduled to start tomorrow. The statuses to filter will remain creating and created.
campaignsIncludeDates: This boolean parameter is set to false as we are not filtering based on a date range but rather a specific start date.
startDate: The start date for the filter, is set to tomorrow's date in epoch format.
status: The campaign status filter, including the statuses creating and created.
To filter the upcoming campaigns based on the criteria mentioned above, ensure that your request payload includes the following parameters:
campaignsIncludeDates = false: This deactivates the date range filtering feature, focusing the filter on a specific start date.
startDate = tomorrow (epoch date): By setting the start date to tomorrow's date in epoch format, the filter will capture any campaigns scheduled to start tomorrow.
status = ["created", "creating"]: Filters the campaigns to include only those that are in the created or creating status and scheduled to start tomorrow.
When a user clicks on an upcoming campaign, they will be redirected to the summary page displaying the campaign details.
For the drafts campaign, we are passing the status as drafted. It will return all the drafts that are in drafted status
For failed campaigns, we are passing the status as failed. It will return all the drafts that are in failed status
When a user clicks on a failed campaign, they will be redirected to the summary page displaying the campaign details. Additionally, a toast message will appear, showing the error that caused the campaign to fail.
Path: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/project-types.json
/project-factory/v1/project-type/search
{ "RequestInfo": { }, "CampaignDetails": { "tenantId": "mz", "status": [ "failed" ], "createdBy": "ff98f9f6-192b-4e12-8e90-7b73dcd0ad4d", "pagination": { "sortBy": "createdTime", "sortOrder": "desc", "limit": 10, "offset": 0 } } }
The checklist requires data from mdms which is configurable and have the following schema codes:
Example Data for the above schema codes// Some code```postman_json
User enters the checklist search screen by clicking on the configure app.
The Search Checklist is the screen where u can search for created checklist and also create checklists for whose templates have been created. View button is present for the created checklists and Configure button for those which need to be created.
The Create Checklist page loads the default template for that particular use role and checklist type and then can be edited as per the user. On submission the api creates the checklist (service definition) and create localisation for all the questions and options
The questions can be Single Choice (Radio button) or Multiple Choice (Checkbox) and each single choice option can have multiple sub questions. Nesting is allowed uptil 3 levels. Nesting can be done by clicking on the Dependency button. Options can also have comments attached to them. Add options and delete options feature is also given. The required checkbox is to make any question mandatory.
Preview Checklist shows the mobile view of the created checklist
The View Checklist page shows the current checklist and is non-editable.
The create and update pages work same. The update checklist page loads the already created questions to be edited and can be reached by clicking the update button on view checklist button.
The following API’s are called while checklist creation :
Question type search: /mdms-v2/v2/_search this is used to search the types of questions like radio button or checkboxes and these are taken from the mdms with schema code HCM-ADMIN-CONSOLE.appFieldTypes
Create: /service-request/service/definition/v1/_create : used to create the service definition which is the checklist.
Upsert: /localization/messages/v1/_upsert All the questions and options are localised by this api under the module name hcm-checklist
The following api is called to view the previously created checklist :
service-request/service/definition/v1/_search
The following API’s are called while checklist update :
Create: /service-request/service/definition/v1/_update : used to update the service definition which is already created.
service-request/service/definition/v1/_create
CAMPAIGN_MANAGER
service-request/service/definition/v1/_update
CAMPAIGN_MANAGER
service-request/service/definition/v1/_search
CAMPAIGN_MANAGER
localization/messages/v1/_upsert
CAMPAIGN_MANAGER
This page allows user to create new Boundary and edit it
Boundary Management works based on the HierarchySchema
Refer this config section to know more
Currently, the default hierarchy name is taken from "type": "default", while the hierarchy where data can be created or edited is defined by "type": "campaign".
The landing page of Boundary Management Screen has three buttons
If the boundary has yet not created then the edit boundary field will be disabled
And clicking on create will ask to use default boundary and data from GeoPoDe or create a complete new one.
Using data from GeoPoDe will load the default boundary and ask to add levels
Creating complete new data will require addition of all levels manually
After creation the levels cannot be edited.
Following API’s are called after clicking the Create button:
Upsert: /localization/messages/v1/_upsert all the names of level localised in to new module named hcm-boundary-${hierarchyName}
Create: /boundary-service/boundary-hierarchy-definition/_create
Download: /project-factory/v1/data/_download A polling mechanism is introduced here which keeps on calling the above api until the status is “completed”
Create: /project-factory/v1/data/_create Data create api called if it’s a new hierarchy and here also a polling mechanism is installed which calls the api /project-factory/v1/data/_search continuously at a fixed interval until the status is “completed”
It will automatically redirect to the view hierarchy screen after successful creation. If any level matches with the default hierarchy then it will use its data. Complete excel sheet can be uploaded for all levels all together after downloading the template and uploading it. (The image below is just for reference and levels can vary)
After uploading the excel user can go to next page and view data and confirm it.
Submitting next will create the data.
Submitting next will create the data.
Edit boundary tab on first boundary page will also land to view hierarchy page as of now and will allow to add new data. View all Boundary data will show all hierarchies and user can download the hierarchies too.
Following API is called after clicking “Create Boundary”:
Create: /project-factory/v1/data/_create the uploaded data in excel is sent to data create api with polling mechanism applied. The search API /project-factory/v1/data/_search is called repeatedly with frequency depending on the size of data and network latency taken from the mdms data using master name “baseTimeout” from module named HCM-ADMIN-CONSOLEuntil status is “completed”.
API Details
project-factory/v1/data/_create
BOUNDARY_MANAGER
project-factory/v1/data/_search
BOUNDARY_MANAGER
project-factory/v1/data/_download
BOUNDARY_MANAGER
localization/messages/v1/_upsert
BOUNDARY_MANAGER
boundary-service/boundary-hierarchy-definition/_create
BOUNDARY_MANAGER
boundary-service/boundary-hierarchy-definition/_search
BOUNDARY_MANAGER
boundary-service/boundary-relationships/_search
BOUNDARY_MANAGER
Find the link below:
UI configuration for the application
This page offers details of the DIGIT UI configuration required to enable it in any environment. Browse through the configuration details listed below:
eGov recommends before developing on top of DIGIT. This ensures that new modules can be developed and deployed in a streamlined way. DIGIT ships with CI as code as part of the DevOps repository. Please run the before developing on DIGIT.
Step 1: Add entry in build-config.yaml file in the master branch of the forked repository. This will set up the job pipeline in Jenkins. Make sure to add the same config to the feature branch you are working on. Refer
Add the below content for digit-ui.
Step 2: Go to the Jenkins build page, select "Job Builder" and click on "Build now". This will pull the config from build_config.yaml and identify all modules that need to be built.
Step 3: Once the build is done, go to your Jenkins build page. The service will appear under the repository path in which it has been added, i.e. if the service is added under frontend, it will show up in the frontend section as below,
Step 2: Deploy-as-code/helm/charts/frontend/digit-ui
Step 1: Locate the following "deploy-as-code/helm/environments/unified-health-dev.yaml" in the DevOps repository of your organization.
Step 2: Add the below code block within the environment YAML file used to deploy the Works platform -
Copy
This section contains the configuration that applies globally to all UI modules. These need to be configured before the configuration of service-specific UI.
Steps to create a globalconfig.js file:
Create a config file (globalconfigs.js) with the below-mentioned config (refer to code below).
Configure all the images/logos required in the S3 and add links as footerBWLogoURL , footerLogoURL.
Mention the state tenant ID as stateTenantId.
If any User roles have to be made invalid add as invalidEmployeeRoles.
Then push this global config file into your S3 bucket as globalconfigs.js
Copy
The S3 bucket has to be configured by the DevOps team, to store all the assets being used in the application like Logos, globalConfigs, etc.
Steps to create a new AWS Bucket -
Create a new AWS S3 Bucket
Update the Bucket Policy with the following content, to make the bucket public
Copy
Update the Cross-Origin Resource Sharing (CORS) configuration with the following content
Copy
To proxy the same bucket in any environment and make the necessary changes in the environment.yaml file located in the DevOps repository's configmaps under egov-config, follow the steps below:
Add the s3-assets-bucket: "pg-egov-assets"
Copy
After adding the proxy in the environment file, restart the s3-proxy build in the environment with config enabled.
This page contains collection consisting of different scenarios of User Uploads which can be done to test in any environments.
These sheets have been created based on following assumptions:
URL -
locale - en_MZ
msgId - 1710912592752|en_MZ
hierarchy Type - ADMIN
project Type - LLIN-mz
Import the environment variable file and collection file in Postman.
Successful run scenario:
When a user adds valid data to the user file.
Example:
When a user uploads a valid sheet with a missing row in between
Example:
Negative run scenarios:
With an empty "Name of the Person (Mandatory)" column.
Example:
With less than 2 letters in "the "Name of the Person (Mandatory)" column.
Example:
Without phone number.
Example:
With invalid values in the phone number column.
Example:
With the same phone number.
Example:
Without data in the role column.
Example:
Without data in the Employment Type column.
Example:
With an empty Boundary Code column.
Example:
With invalid values in the Boundary Code column.
Example:
Test Run collection -Passed
Project factory service has a dependency on Kafka, Postgres, and Redis.
Changes in the HELM -
Auto-generate user password:
1. Password Management
Auto-generate user password:
Enables the system to generate a random password for new users.
Set a default user password:
Specifies a default password to be used if auto-generation is disabled.
2. User Duplication Check
Skip user creation if a mobile number already exists:
Prevents the creation of duplicate users by checking existing mobile numbers.
3. Tab Naming for Readme and Sheets
Readme Tab Name:
Defines the sheet name to be used for the ReadMe tab.
Tab names for different data sheets:
Sets tab names for facilities, boundary data, and user lists in the HCM Admin Console.
Localization and Default Locale
Set default locale:
Defines the default locale as "en_IN" unless overridden in the Helm values.
Localization module:
Specifies the localization module used for HCM schemas.
5. Logging Configuration
Set application log level:
Determines the verbosity of logs, defaulting to "info."
Set maximum debug characters:
Limits the maximum length of debug logs to 500 characters unless overridden.
6. User Mapping
Enable mapping users via a common parent:
Allows users to be linked based on a shared parent hierarchy.
7. Automatic Retry Mechanism
Retry when specific HTTP errors occur:
Automatically retries operations if the "socket hang up" error occurs.
8. Localisation wait time in Boundary Creation
Localisation wait time in Boundary Creation
9. Localisation Chunk Size
Localisation Chunk Size
The configuration snippet provides the details required to set up and connect to a database, including environment-specific handling, credentials, schema information, and other related settings. Below is a structured breakdown:
Database Connection Information
Flyway Migration Information
General Notes
ConfigMap and Secrets Integration: Sensitive data like DB_USER, DB_PASSWORD, and Flyway credentials are securely retrieved from Kubernetes secrets (db secret). Non-sensitive configurations like DB_HOST and DB_NAME are stored in ConfigMaps (egov-config).
Namespace-Specific Configuration: The DB_URL and DB_SCHEMA are tailored for specific namespaces. For example, the "health" namespace uses a dedicated health-db-url key and the namespace value for the schema.
Default Settings: Where applicable, defaults are provided. For instance, the schema defaults to "public" and the port defaults to 5432.
These configurations enhance the flexibility and usability of the Project Factory Service, ensuring smoother operations and better alignment with user needs.
This step involves executing the Postman collection for collective creation of hierarchical data, file uploads, template generation, validation, and campaign creation within the same
Import the environment variable file and collection file in Postman.
Click on the Import button and drop both files.
Go to the Environment tab on the left side and click on it.
Certain values of environment variables should be changed depending on the following:
URL: This depends on the environment being used (for example, development, staging, production).
tenantid: Identifies the specific tenant for which the operations are being performed.
projecttype: Specifies the type of project, which can be either "LLIN-mz" or "MR-DN" (MDMS configuration).
locale: Defines the locale/language for localization purposes (e.g., en_IN for English in India, en_MZ for English in Mozambique).
msgId: Unique identifier combined with locale (e.g., 1710912592752|en_MZ). In msg id, change as per the locale used.
Go to the collection tab on the left side and click on it.
Start executing the script one by one.
In Filestore upload API, upload the Excel sheet in the file field by uploading the valid file. You will get a filestore id in response.
For example, A valid file can be created - if hierarchyType is "MH" and the sheet has 6 levels consisting of COUNTRY, PROVINCE, DISTRITO, POST ADMINISTRATIVE, LOCALITY and VILLAGE. Change the sheet name to MH_COUNTRY, MH_PROVINCE, MH_DISTRITO, MH_POST ADMINISTRATIVE, MH_LOCALITY, and MH_VILLAGE and all the boundaries as per hierarchy and upload the Excel sheet.
The sample sheet with valid data is given below:
From 13. check the Excel with filestore Target API, and click on the filestore link by clicking on ctrl+click. It will download the target file.
From 14. filestore upload target API. After downloading the file, upload the valid file by filling in the target column in the sheet. You will get a filestore id in response.
Sample Sheet:
From 17, check the Excel with filestore API. Click on the filestore link (ctrl+click). It will download the facility file.
From 18, filestore upload Facility API; after downloading the file, upload the valid file by filling in the facility usage and boundary code column in the sheet. You will get a filestore id in response.
Sample Sheet:
From 21, check the Excel with filestore API, and click on the filestore link by pressing ctrl+click. It will download the user file.
From 22, filestore upload User API. After downloading the file, upload the valid file by filling in all columns in the sheet. You will get a filestore id in response.
Sample Sheet:
From 32, check user creds Excel. You will be able to get the user credentials Excel sheet by clicking on the filestore link (ctrl+click).
In the user credentials sheet, you will be able to see the username and password to log into the app.
Sample Sheet:
This page contains collection consisting of different scenarios of Target Uploads which can be done to test in any environments.
These sheets have been created based on following assumptions :
Url -
locale - en_MZ
msgId - 1710912592752|en_MZ
hierarchy Type - ADMIN
project Type - LLIN-mz
Import environment variable file and collection file in Postman.
Successful run scenario:
With a valid range of numbers in the 'Target' column.
Example:
Negative run scenario:
With an empty 'Target' column.
Example:
With invalid values in the 'Target' column (max, min, date, negative, zero, decimal values).
Collection runner result - Passed.
This page contains collection consisting of different scenarios of Facility Uploads which can be done to test in any environments.
These sheets have been created based on following assumptions :
Url -
locale - en_MZ
msgId - 1710912592752|en_MZ
hierarchy Type - ADMIN
project Type - LLIN-mz
Import environment variable file and collection file in Postman:
Successful run scenarios:
Valid file with correct values in all columns.
Example:
With a valid file with a missing row in between.
Example:
Negative run scenarios:
With an empty "Facility Usage" column.
Example:
With all inactive values for the "Facility usage" column.
Example:
With an empty "Boundary Code" column.
Example:
With duplicate names in the "Facility Name" column.
Example:
With an empty "Facility Name" column.
Example:
With an invalid value in the "Facility Name" column.
With an empty "Facility Type" column.
With an empty "Facility Status" column.
With empty and invalid values in the 'Capacity' column (max, min, date, negative, zero values).
With empty and invalid values in the "Boundary Code" column.
Collection runner result -passed:
To learn more about the and process visit
Step 1: Add an entry in the helm chart of the frontend directory in the master branch of the forked repository.
Step 3: Modify the development environment as per requirements.
Mention the globalconfig file URL in your .
Name
5555627761
Distributor
Permanent
ADMIN_MO_07_MAPUTO CITY
Name
5555627761
Distributor
Permanent
ADMIN_MO_07_MAPUTO CITY
5555627761
Distributor
Permanent
ADMIN_MO_07_MAPUTO CITY
N
5555627761
Distributor
Permanent
ADMIN_MO_07_MAPUTO CITY
Name
Distributor
Permanent
ADMIN_MO_07_MAPUTO CITY
Name
6347374
Distributor
Temporary
ADMIN_MO_07_MAPUTO CITY
Name1
ABC23
Distributor
Permanent
ADMIN_MO_07_MAPUTO CITY
Name
6347374748
Distributor
Temporary
ADMIN_MO_07_MAPUTO CITY
Name1
6347374748
Distributor
Permanent
ADMIN_MO_07_MAPUTO CITY
Name
6347374748
Temporary
ADMIN_MO_07_MAPUTO CITY
Name1
6347374748
Permanent
ADMIN_MO_07_MAPUTO CITY
Name
6347374748
Distributor
ADMIN_MO_07_MAPUTO CITY
Name1
6347374748
Distributor
ADMIN_MO_07_MAPUTO CITY
Name
6347374748
Distributor
Temporary
Name1
6347374748
Distributor
Permanent
Name
6347374748
Distributor
Temporary
ABC
Name1
6347374748
Distributor
Permanent
111
KAFKA_BROKER_HOST
egov-config
kafka-brokers
EGOV_MDMS_HOST
egov-service-host
egov-mdms-service
EGOV_MDMS_V2_HOST
egov-service-host
mdms-service-v2
EGOV_FILESTORE_SERVICE_HOST
egov-service-host
egov-filestore
EGOV_IDGEN_HOST
egov-service-host
egov-idgen
EGOV_FACILITY_HOST
egov-service-host
facility
EGOV_BOUNDARY_HOST
egov-service-host
boundary-service
EGOV_PROJECT_HOST
egov-service-host
health-project
EGOV_USER_HOST
egov-service-host
egov-user
EGOV_PRODUCT_HOST
egov-service-host
product
EGOV_HRMS_HOST
egov-service-host
health-hrms
EGOV_LOCALIZATION_HOST
egov-service-host
egov-localization
EGOV_HEALTH_INDIVIDUAL_HOST
egov-service-host
health-individual
EGOV_AUDIT_HOST
egov-service-host
audit-service
EGOV_PLAN_SERVICE_HOST
egov-service-host
plan-service
EGOV_CENSUS_HOST
egov-service-host
census-service
FILE_STORE_SERVICE_END_POINT
filestore/v1/files
EGOV_MDMS_V2_SEARCH_ENDPOINT
mdms-v2/v2/_search
EGOV_MDMS_V1_SEARCH_ENDPOINT
mdms-v2/v1/_search
EGOV_IDGEN_PATH
egov-idgen/id/_generate
EGOV_MDMS_SCHEMA_PATH
mdms-v2/schema/v1/_search
EGOV_BOUNDARY_RELATIONSHIP_SEARCHPATH
boundary-service/boundary-relationships/_search
EGOV_BOUNDARY_SERVICE_SEARCHPATH
boundary-service/boundary/_search
EGOV_BOUNDARY_HIERARCHY_SEARCHPATH
boundary-service/boundary-hierarchy-definition/_search
HEALTH_PROJECT_CREATE_PATH
health-project/v1/_create
EGOV_PROJECT_STAFF_CREATE_PATH
health-project/staff/v1/_create
EGOV_PROJECT_RESOURCE_CREATE_PATH
health-project/resource/v1/_create
EGOV_PROJECT_RESOURCE_FACILITY_PATH
health-project/facility/v1/_create
EGOV_USER_SEARCH_PATH
user/_search
EGOV_FACILITY_SEARCH_PATH
facility/v1/_search
EGOV_PRODUCT_VARIANT_SEARCH_PATH
product/variant/v1/_search
EGOV_BOUNDARY_ENTITY_SEARCHPATH
boundary-service/boundary/_search
EGOV_FACILITY_BULK_CREATE
facility/v1/bulk/_create
EGOV_HEALTH_INDIVIDUAL_SEARCH
health-individual/v1/_search
EGOV_PLAN_FACILITY_SEARCH
plan-service/plan/facility/_search
EGOV_PLAN_FACILITY_CONFIG_SEARCH
plan-service/config/_search
EGOV_CENSUS_SEARCH
census-service/_search
EGOV_PLAN_SEARCH
plan-service/plan/_search
KAFKA_SAVE_CAMPAIGN_DETAILS_TOPIC
save-campaign-details
KAFKA_UPDATE_CAMPAIGN_DETAILS_TOPIC
update-campaign-details
DB_URL
health-db-url or db-url from egov-config
URL for connecting to the database. Uses health-db-url in the "health" namespace, else db-url.
DB_HOST
db-host from egov-config
Hostname or IP address of the database server.
DB_PORT
"5432"
Port number for database connection (default PostgreSQL port).
DB_NAME
db-name from egov-config
Name of the database being connected to.
DB_SCHEMA
Namespace value or "public"
Specifies the schema within the database. Defaults to "public" if no namespace is provided.
DB_USER
username from db secret
Database username used for authentication.
DB_PASSWORD
password from db secret
Database password for authentication.
FLYWAY_USER
flyway-username from db secret
User for running Flyway migrations.
FLYWAY_PASSWORD
flyway-password from db secret
Password for Flyway migration user.
FLYWAY_LOCATIONS
flyway-locations from egov-config
Directory or path for Flyway migration scripts.
SCHEMA_TABLE
schemaTable from initContainers.dbMigration
Table name for tracking Flyway migrations.
Auth token: Obtains credentials required to execute the collection.
Create boundary-hierarchy-definition: Creates a new hierarchy definition.
Search boundary-hierarchy-definition: Searches for a hierarchy definition created by the user.
F ilestore upload: Uploads boundaries stored in an Excel file.
Boundary bulk upload: Uploads boundaries for previously created hierarchies.
Boundary relationship search API: Searches relationships of boundary uploads within a specified hierarchy.
Upsert localisations: Inserts or updates localizations for headers related to hierarchy names in a spreadsheet.
Search Localisations: Verifies if localisations have been successfully created.
Campaign create draft: Initiates the creation of a campaign with project type, name, start/end dates, delivery rules, and selected boundaries.
Campaign search: Searches the drafted campaign
Template Generate API - boundary: Generates a template for uploading targets.
Template Download API - boundary: Retrieves Filestore ID generated from template generate API for boundary templates.
Get Excel: Fetches and downloads the Excel file associated with a Filestore ID.
Filestore upload: Uploads a target file by filling in all necessary data.
Template Generate API - facility: Generates a template for uploading facilities.
16.Template Download API - facility: Retrieves Filestore ID generated from Template Generate API for facility templates.
Get Excel: Fetches and downloads the Excel file associated with a Filestore ID.
Filestore upload: Uploads a facility file by filling in all necessary data.
Template Generate API - user: Generates a template for uploading users.
Template Download API - user: Retrieves Filestore ID generated from Template Generate API for user templates.
Get Excel: Fetches and downloads the Excel file associated with a Filestore ID.
Filestore upload: Uploads a user file by filling in all necessary data.
Validate resource boundary: Checks the correctness of an uploaded boundary file.
Search API: Searches for the validated boundary file.
Validate resource facility: Checks the correctness of an uploaded facility file.
Search API: Searches for the validated facility file.
Validate resource user: Checks the correctness of an uploaded user file.
Search API: Searches for the validated user file.
Campaign create: Creates a campaign using resource IDs and Filestore IDs validated through previous APIs.
Campaign search API: Searches for a campaign and checks its status (creating, created, or failed).
Search API - user creds: Fetches user credentials resource ID.
Check user creds Excel.
Yarnee
Klagbe Clinic
Klagbe Town
Pailey Towns
101
Yarnee
Klagbe Clinic
Klagbe Town
Pailey test town
102
Yarnee
Klagbe Clinic
Klagbe Town
Pailey Towns
Yarnee
Klagbe Clinic
Klagbe Town
Pailey test town
Yarnee
Klagbe Clinic
Klagbe Town
Pailey Towns
-1
Yarnee
Klagbe Clinic
Klagbe Town
Pailey test town
0
Yarnee
Klagbe Clinic
Klagbe Town
Pailey test town
1.11
Yarnee
Klagbe Clinic
Klagbe Town
Pailey test town
AB$$
Yarnee
Klagbe Clinic
Klagbe Town
Pailey test town
12/04/24
Yarnee
Klagbe Clinic
Klagbe Town
Pailey test town
1000000000
Facility bednet for MZ
Storing Resource
Permanent
200
ADMIN_MO
Active
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
ADMIN_MO_07_06_03_KLAGBE CLINIC
Inactive
Facility bednet for MZ
Storing Resource
Permanent
200
ADMIN_MO
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
ADMIN_MO_07_06_03_KLAGBE CLINIC
Facility bednet for MZ
Storing Resource
Permanent
200
ADMIN_MO
Inactive
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
ADMIN_MO_07_06_YARNEE
Inactive
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
ADMIN_MO_07_06_03_KLAGBE CLINIC
Inactive
Facility bednet for MZ
Storing Resource
Permanent
200
Active
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
Inactive
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
Inactive
FAC1
Storing Resource
Permanent
200
ADMIN_MO
Active
FAC1
Storing Resource
Permanent
200
ADMIN_MO_07_06_YARNEE
Active
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
ADMIN_MO_07_06_03_KLAGBE CLINIC
Inactive
Storing Resource
Permanent
200
ADMIN_MO
Active
Storing Resource
Permanent
200
ADMIN_MO_07_06_YARNEE
Inactive
Storing Resource
Permanent
200
ADMIN_MO_07_06_03_KLAGBE CLINIC
Inactive
//////
Storing Resource
Permanent
200
ADMIN_MO
Active
Facility bednet for MZ
Permanent
200
ADMIN_MO
Active
Facility bednet MDA-LF-Nairobi
Permanent
200
ADMIN_MO_07_06_YARNEE
Inactive
Facility bednet MDA-LF-Nairobi
Permanent
200
ADMIN_MO_07_06_03_KLAGBE CLINIC
Inactive
Facility bednet for MZ
Storing Resource
200
ADMIN_MO
Active
Facility bednet MDA-LF-Nairobi
Storing Resource
200
ADMIN_MO_07_06_YARNEE
Inactive
Facility bednet MDA-LF-Nairobi
Storing Resource
200
ADMIN_MO_07_06_03_KLAGBE CLINIC
Inactive
Facility bednet for MZ
Storing Resource
Permanent
-11
ADMIN_MO
Active
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
0
ADMIN_MO_07_06_YARNEE
Inactive
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
12/03/24
ADMIN_MO_07_06_03_KLAGBE CLINIC
Inactive
Facility bednet for MZ
Storing Resource
Permanent
200
2454
Active
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
aaa
Inactive
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
111 CLINIC
Inactive
The Health Campaign Management (HCM) app has achieved remarkable success, and we want to build on this momentum. While setting up a campaign currently involves considerable developer support, we are turning this into an opportunity for improvement. In this regard, we are introducing the HCM Console, an innovative solution designed to empower users to create and manage campaigns effortlessly, enhancing overall efficiency and streamlining the process.
Who is the HCM Console for?
HCM Console is designed for individuals familiar with the on-ground execution of health campaigns. These users understand key terms like cycles, deliveries, doses, boundaries, and campaign hierarchies. However, they are not expected to be tech-savvy, and we aim to eliminate the need for them to grasp technical concepts like JSON files, schemas, APIs, MDMS, services, or intricate UI/UX designs. In short, HCM Console prioritises intuitive user experience with extensive guidance throughout the campaign creation and execution process.
Version 0.3 focuses on empowering users to do the following:
Dual Timeline view for campaign creation
Boundary Data management
Adding/Editing Users for upcoming and ongoing campaigns
Adding/Editing Targets for upcoming and ongoing campaigns
Adding/Editing Facilities for upcoming and ongoing campaigns
Adding Boundaries for upcoming and ongoing campaigns
IRS enablement on Console
Checklist Module Management
These features, cumulatively, will allow users to create the core structure of their campaigns within version 0.3. Subsequent releases will introduce advanced functionalities like the form engine for customising individual and household registration forms, and enhanced data capture functionalities for side effects, refusals, and referrals. It is important to note that the HCM app will continue to support these advanced features in the interim, and the impel team will be responsible for any necessary changes or customisations until their official release within the Campaign Manager.
By introducing the HCM Console, we aim to significantly reduce the time and effort required to set up campaigns within the HCM app, empowering users to take greater ownership and expedite campaign implementation. This user-centric approach translates to enhanced campaign efficiency, allowing our team to focus on further optimising and scaling the HCM app for even greater impact.
Facility bednet for MZ
Storing Resource
Permanent
200
ADMIN_MO
Active
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
ADMIN_MO_07_06_YARNEE
Inactive
Facility bednet MDA-LF-Nairobi
Storing Resource
Permanent
200
ADMIN_MO_07_06_03_KLAGBE CLINIC
Inactive
Campaign Creation Flow from Microplan Data
project-factory:v0.3.0-8072220bb1-256
updated
workbench-ui:v0.3.0-9c780fe20f-703
updated
health-project:v1.1.5-3f860f8a31-81
updated
ServiceRequest
service-request:dev-26763cf493-37
updated
plan-service:v1.0.0-fd9a00f0e7-230
To check the Microplan Integrated flow
census-service:v1.0.0-fd9a00f0e7-75
To check the Microplan Integrated flow
microplan-ui
microplan-ui:v0.3.0-a34f1db2c0-1
To check the Microplan Integrated flow
core-ui
core-ui:v0.3.0-a34f1db2c0-1
To test the performance
0.3 tag added
0.3 tag added
0.3 tag added
we added the seed data as part of release kit
HCM Admin Console v0.2
project-factory:v0.2.0-1ea8b5b5b9-9
updated
workbench-ui:v0.2.0-6f08f64238-535
updated
HCM v1.5
health-project:v1.1.5-8208b6fc8f-69
updated
DEVOPS v0.2
0.2 tag added
CONFIGS v0.2
0.2 tag added
Localisation v0.2
0.2 tag added
MDMS v0.2
we added the seed data as part of release kit
Click here to know more.
As the adoption of the HCM app is beginning to increase, a significant piece of feedback we have received is that setting up any campaign on the HCM app currently demands a minimum of two weeks of development effort. There is a consensus that the lead time for campaign setup needs to be shortened.
The concept involves transforming the HCM app into a SaaS-like product, featuring a console that empowers the admin user, in this case, the campaign manager, to effortlessly create and execute campaigns on the HCM app. The Campaign Manager product will offer the admin user the flexibility to select and customise specific components of the HCM app according to their preferences.
The user persona for this product is anyone who knows how a given health campaign works on the ground. They have a decent understanding of terms and concepts such as Cycles, Deliveries, Doses, Boundaries, Hierarchy, and other Campaign-related terminologies.
The challenge is around the ability of the user to use and understand technology. The user is not tech-savvy and is not expected to know concepts of JSON Files, Schemas, APIs, MDMS, Services, and any other such terms. The user is also not expected to be well-versed in high-fidelity UX/UI and needs every bit of hand-holding possible during the process of creating and running a campaign.
Reduce set-up time for new campaigns.
Reduce dependence on engineering resources for setting up a new campaign.
Provide the power to the end user for customising campaigns.
Sr. No.
Theme
Assumption
1
User persona
The user is well-versed with campaign terminologies and has some level of previous campaign management experience.
2
Device type
The product will be used as a web-based application with an internet connection.
Sr. No.
Role
Action
1
Campaign Manager
Select Campaign Type
Assign Campaign Name
Set Campaign Dates
Configure Boundary Data
Configure Facilities
Configure Users
Set Rules for Delivery
Question
Input Field Type
Validations/Limitation
Which campaign type do you want to run?
Dropdown single selection
Users can select only one campaign at a time. The entries in this drop-down will be pre loaded from the back end. Will provide the functionality of updating the list to the users from UI.
What is the name of your campaign?
Open text field
Limit of 50 characters.
Beneficiary type for the selected campaign is
Non-editable field
The answer to this question can only be household or individual based on the campaign name selected in the previous question.
Select the start and end dates of the campaign for the boundaries selected above. Note: This date range will be applicable to all boundaries selected in the previous question.
Calendar selection Icon with 2 inputs:
Start Date
End Date
The selection will ask for 2 inputs from the user:
Start and end dates. The user cannot select start or end dates from the past. only future date selections should be allowed. By default, when the selection opens, the date should be set to today's date.
Boundary data: If the boundary data is updated regularly, then the analytics for the long-term will not have data sanity.
Users might have issues uploading multiple Excel sheets for targets, facility, and user data.
Boundary data mapping and hierarchy changes through UI will not be allowed. If the user wants to edit/add new boundary data, it will be raised through the L1 team.
Editing of campaign data, once the campaign is live through the HCM Console UI, is not allowed. The changes will have to be routed through the implementation team.
Language selection for the app will not be a part of this release.
Click here to learn more.
This document describes the web flow for updating an existing campaign using the Admin Console. The process involves interactions between the user and several backend services, ensuring the campaign data is updated correctly and validated before finalizing changes.
User: The person interacting with the Admin Console to update an existing campaign.
CampaignManager (Admin Console): The primary interface that the user uses to manage and update campaign information.
ProjectFactory: Responsible for handling the creation and updating of campaign objects and validating the data.
BoundaryService: Provides the boundary hierarchy definitions and relationship data necessary for the campaign.
MDMSService: Supplies master data such as project types, hierarchy configurations, and other templates.
FileStoreService: Manages the storage and retrieval of files related to the campaign.
User: Begins the update process by selecting an existing campaign from the "My Campaign" screen within the Admin Console.
CampaignManager: Receives the request to update a specific campaign and retrieves the campaign object using its unique ID.
CampaignManager sends a request to ProjectFactory to fetch the campaign object based on the provided campaign ID.
ProjectFactory responds with the campaign object containing the current campaign details.
CampaignManager requests BoundaryService to fetch boundary hierarchy definitions based on the campaign's hierarchy type.
BoundaryService responds with the boundary hierarchy definition.
CampaignManager requests BoundaryService to fetch boundary relationship data based on the hierarchy type.
BoundaryService responds with the boundary relationship data.
User: Updates the necessary fields, such as boundary delivery configuration and other campaign-specific details, using the Admin Console.
CampaignManager: Sends the updated information to ProjectFactory to create or update the campaign object, storing it with an action status of "draft".
ProjectFactory: Automatically triggers the generation of templates for different resources, including:
Target templates
Facility templates
User templates
User: Downloads the generated templates for each resource type via the Admin Console.
CampaignManager: Sends a request to FileStoreService to store the downloaded files.
FileStoreService responds with a filestoreid that uniquely identifies the stored file.
CampaignManager: Sends the data and the filestoreid to ProjectFactory for validation.
ProjectFactory responds with a unique validation ID, as the validation process may take some time.
CampaignManager: Periodically checks the validation status using the unique validation ID.
ProjectFactory:
If validation is successful:
Responds with a success message.
CampaignManager: Displays a success message to the user, indicating that they can proceed to the next step.
If validation fails:
Responds with an error message detailing the validation failure.
CampaignManager: Displays the error message to the user, prompting them to correct the errors and re-upload the files.
User: Once all required data is filled in and validated, the user reviews the summary of the campaign data and clicks on the "Update Campaign" button.
CampaignManager: Sends a request to ProjectFactory with the campaign update API, marking the action as "update".
ProjectFactory:
If the update is successful:
Responds with a success message, indicating that the campaign update has started.
CampaignManager: Displays a success message to the user, confirming that the campaign has been updated successfully.
If the update fails:
Responds with an error message detailing the failure.
CampaignManager: Displays the error message to the user, prompting them to correct any issues and try again.
Validation Failures: If validation fails at any stage (e.g., during file validation or input data checks), the CampaignManager will notify the user of the specific issues. The user must resolve these issues and re-upload the necessary data to proceed.
Service Errors: If any of the services (e.g., BoundaryService, ProjectFactory) encounter an error during processing, the CampaignManager will display an error message, detailing the problem and suggesting corrective actions.
This document outlines the flow for updating an existing campaign using the Admin Console. The structured sequence ensures that any changes to the campaign are thoroughly validated and processed, minimizing errors and ensuring the integrity of the campaign data. By following this flow, users can confidently update campaigns, knowing that all necessary steps are taken to verify and finalize their changes.
This document details the web flow for creating a new campaign using the Admin Console. The process involves interactions between various services, including the Project Factory, Boundary Service, MDMS Service, FileStore Service, and the Admin Console. This flow ensures that all necessary data is collected, validated, and processed to create a campaign successfully.
User: The person interacting with the Admin Console to set up and create a campaign.
CampaignManager (Admin Console): The main interface that the user interacts with to manage campaign creation.
ProjectFactory: Handles the creation and management of campaign objects and validation processes.
BoundaryService: Provides information about boundary hierarchy and relationships.
MDMSService: Supplies master data such as project types, hierarchy configurations, and operator details.
FileStoreService: Manages the storage and retrieval of files related to the campaign.
User: Initiates the process by visiting the Admin Console to set up a new campaign.
CampaignManager: Receives the request to set up a campaign and starts interacting with various services to gather necessary information.
CampaignManager sends a request to MDMSService to fetch required master data, including:
Project types
Hierarchy type configuration
Operator templates
Other necessary templates
MDMSService responds with the requested master data, which is used to configure the campaign.
CampaignManager requests BoundaryService to fetch boundary hierarchy definitions based on the selected hierarchy type.
BoundaryService responds with the boundary hierarchy definition.
CampaignManager requests BoundaryService to fetch boundary relationship data based on the selected hierarchy type.
BoundaryService responds with the boundary relationship data.
User: Fills in the required data such as boundary delivery configuration and other campaign-specific details within the Admin Console.
CampaignManager: Sends the user-filled information to ProjectFactory to create a campaign object and stores it with an initial action status of "draft".
ProjectFactory: Automatically triggers the generation of templates for different resources, including:
Target templates
Facility templates
User templates
User: Downloads the generated templates for each resource type through the Admin Console.
CampaignManager: Sends a request to FileStoreService to store the downloaded files.
FileStoreService responds with a filestoreid that uniquely identifies the stored file.
CampaignManager: Sends the data and the filestoreid to ProjectFactory for validation.
ProjectFactory responds with a unique validation ID as the validation process may take some time.
CampaignManager: Periodically checks the status of the validation using the unique validation ID.
ProjectFactory:
If validation is successful:
Responds with a success message.
CampaignManager: Displays a success message to the user, indicating that they can proceed to the next step.
If validation fails:
Responds with an error message detailing the validation failure.
CampaignManager: Displays the error message to the user, prompting them to correct the errors and re-upload the files.
User: Once all required data is filled in and validated, the user reviews the summary of the campaign data and clicks on the "Create Campaign" button.
CampaignManager: Sends a final request to ProjectFactory with the campaign creation API, marking the action as "create".
ProjectFactory:
If the creation is successful:
Responds with a success message indicating that the campaign creation has started.
CampaignManager: Displays a success message to the user, confirming the campaign creation.
If the creation fails:
Responds with an error message detailing the failure.
CampaignManager: Displays the error message to the user, prompting them to correct any issues and try again.
Validation Failures: If validation fails at any stage (e.g., during file validation or input data checks), the CampaignManager will notify the user of the specific issues. The user must resolve these issues and re-upload the necessary data to proceed.
Service Errors: If any of the services (e.g., BoundaryService, MDMSService, ProjectFactory) encounter an error during processing, the CampaignManager will display an error message, detailing the problem and suggesting corrective actions.
This document outlines the end-to-end flow for creating a new campaign using the Admin Console. It ensures that the user provides all required information, and that data is validated and processed correctly to create the campaign. This structured approach minimizes errors and ensures that all campaigns are set up with the required accuracy and completeness.
/project-factory/v1/project-type/fetch-from-microplan
This document describes the web flow for updating an existing campaign by integrating the existing microplan with the console. This process involves the integration of several backend services to update the data in the facility, target, and user sheet in the existing campaign object.
Core Services
Plan Service
Census Service
Initiating Request: The request body for the microplan integration will be:
Validations:
This request validates whether the campaignId and planConfigurationId exist in the system or are invalid.
Facility Sheet Updation:
The process begins by searching for the facility associated with the planConfigurationId, which provides details about the facility code and the linked service boundaries. Next, a facility sheet is generated for the campaign. Once the facility sheet is obtained, the service boundaries are populated within the sheet where the specific facility code is present.
After completing the facility sheet, it is validated using the Validate API. Once validation is successful, the campaign object is updated with the new facilityId and resourceId.
We get the data to fill in this sheet from plan-service/plan/facility/_search where data is like this and map the facilityId to the serviceBoundaries.
Target Sheet Updation:
The process begins by performing a plan census search using the planConfigurationId, which retrieves details about the boundary code and its associated census data. After obtaining the mapping between the boundary code and the linked census, a target sheet of type boundary is generated for the campaign and hierarchy by invoking the Generate API.
A predefined MDMS schema ensures accurate mapping between the headers in the target sheet and the fields in the data. This schema acts as a blueprint, defining the correspondence between the data fields and their respective headers in the generated sheet. For this sheet, we get the data from census search API where the data looks like this:
The sample data for filling the target sheet is:
Here, the type of the target sheet is constructed as Target-<projectType> of the campaign.
to: This specifies the key to be extracted from the census object.
from: These are the keys representing the headers that need to be enriched in the generated sheet.
This mapping ensures that the data from the census object is correctly aligned and populated into the appropriate headers in the target sheet.
After populating the worksheet with data from the census objects, the file is uploaded to the filestore. Next, the sheet is validated using the Validate API with the type boundaryWithTarget. Once the validation is completed, the campaign object is updated with the newly generatedfilestoreId and resourceId.We get data from census search as follows:
User Sheet Updation:
The process begins by fetching the plan associated with the planConfigurationId and retrieving the boundaries from the campaign details, specifically those of type LOCALITY. Next, for each locality, the count of all roles is obtained from the plan search response. This role count is then enriched in the corresponding sheet for that locality.
To map the roles and their requirements for determining the role count in the plan facility response, the predefined MDMS schema for the target is utilized. In this schema:
to: Represents the role to be mapped.
from: Specifies an array of keywords that must be present in the key to identify the role.
This ensures accurate and efficient mapping and population of role-related data in the sheet. Also used -
Added a field consolidateUsersAt in the schema to filter for boundaries based on a particular hierarchy; Example: LOCALITY Sample Data:
Sample MDMS data:
After populating the sheet with the appropriate information, the sheet is validated by calling the Validate API with the type userWithBoundary. Once the validation is successful, the campaign object is updated accordingly. We get the data to fill in this sheet from this API:
This document outlines the process for updating an existing campaign by integrating a microplan through the admin console. It involves validating the campaignId and planConfigurationId and updating the facility, target, and user sheets using data from backend services.
Facility Sheet: Generated using facility details from the planConfigurationId, enriched with service boundaries, validated, and updated in the campaign object.
Target Sheet: Created by mapping census data to boundary codes using the MDMS schema. The sheet is populated, validated, uploaded, and updated in the campaign object.
User Sheet: Locality boundaries are fetched, role counts are calculated and enriched using the MDMS schema, and the sheet is validated before updating the campaign object.
This integration ensures accurate, automated updates and efficient campaign management.
This flow comes in picture if u have parentId present in your request body and that parent campaign should be in created state.
In case parent campaign is present-
Introduced two new columns in Campaign Details table i.e isActive(boolean) and parentId (string)
Validate Parent Campaign(if parentId present)
If actionInUrl is create ,then parentCampaign should be active or isActive of parentCampaign should be true.
If actionInUrl is update, then parentCampaign should be inActive or isActive of parentCampaign should be false.
Validate Boundaries (If Parent Campaign Present)
1. Boundaries array in new Campaign should contain only newly added boundaries and the existing boundaries are fetched from parent Campaign and new boundaries are formed by merging both.
If actionInUrl is create and parentCampaign is present ,call the generate of templates of all three types(boundary, user, facility) .
Create Project -
If new boundaries are selected in update flow , then projects are created only for those newly added boundaries.
If existing targets are updated then update project is called with updated project target mappings.
Edit generated facility and user sheets -
Once you are in update campaign flow, you can edit the existing facility mappings to boundary codes and also make it inactive or active and this would subsequently update the mappings like Project Facility and Project Staff mappings .
Retry Mechanism -
If campaign fails ,we have added retry feature so that it can be restarted from same point where it failed(needs more optimisation).
Update Campaign Object-
Multiple Updates of a Campaign
Once the ongoing campaign is updated and reaches the "Created" state, the updated sheet templates (i.e., Facility, User, and Target) are consolidated back into the format used during the initial "Create" flow.
This ensures that when you attempt to update the campaign again, it will be treated as the first update.
Retry API Payload
Generate API for Boundary
Base URL: project-factory/v1/
Endpoint: /data/_generate
Method: POST
Request Structure:
Body Parameters:
RequestInfo: Object containing RequestInfo
Query Parameters:
tenantId: Tenant
type: Type of Resource (e.g., boundary)
forceUpdate: Boolean type (either true or false)
hierarchyType: Name of Boundary Hierarchy
campaignId: CampaignId
Response Structure:
Success Response:
Client Initiates Request:
The client initiates a dataGenerate request to the Project Factory Service.
Validation of Request:
Schema Validation: Validate against generateRequestSchema.
Tenant ID Validation: Ensure tenantId matches in query and RequestInfo.userInfo.
Force Update: Default to "false" if missing.
Hierarchy Type Validation: Validate hierarchyType for the tenantId.
Processing of Generate Request:
Fetch Data from DB:
Retrieve data using getResponseFromDb(request).
Modify Response Data:
Modify the fetched data with getModifiedResponse(responseData).
Generate New Entry:
Create a new entry with getNewEntryResponse(request).
Expire Old Data:
Update the status of old data to expired using getOldEntryResponse(modifiedResponse, request).
Persist Data Changes:
Call updateAndPersistGenerateRequest(newEntryResponse, oldEntryResponse, responseData, request).
Purpose:
If forceUpdate is true and data exists: Mark existing data as expired and create new data.
No data exists or force update is true: Generate new data.
If forceUpdate is false and data exists: Return the old data.
Boundary Data Processing:
Generate new Boundary Data:
Fetch Boundary Relationships.
If no boundary is found, generate an empty boundary sheet.
Fetch Filters from CampaignId and generate Boundary Data based on those Filters.
If Filters is null, it will generate the whole Boundary Data.
After the Boundary Sheet has been generated, append the ReadMeSheet.
Generate different tabs based on any boundary level configured (here District).
Generating Different Boundary Templates based on Campaign Type
Fetch configurable columns from mdms present for each campaign type from schema -[HCM-ADMIN-CONSOLE.adminSchema].
Here is a sample data from the given schema having configurable columns for Campaign SMC-
Handle Error:
Update status to failed, add error details, log the error, and produce a message to the update topic.
Downloading the generated boundary template through /data/_generate API:
One can get the filestoreId through the /data/_download API which will fetch from db using the id from the response of /data/_generate API.
Note:
Downloaded Template will have one ReadMe sheet, one Boundary Data Tab, and all other tabs on a number of unique districts(or whichever level configured).
Target Upload API
Base URL: project-factory/v1/
Endpoint: /data/_create
Method: POST
Request Structure:
Body Parameters:
RequestInfo: Object Containing RequestInfo
ResourceDetails: Details of a given Resource
type: Type of resource to create (e.g., boundarywithTarget)
tenantId: Tenant
fileStoreId: FileStoreId of Target Upload Sheet
action: Action to perform (e.g., validate for target upload)
hierarchyType: Name of Boundary Hierarchy
campaignId: CampaignId
additionalDetails: Additional details (optional)
Response Structure:
Success Response:
ResponseInfo: Object Containing ResponseInfo
ResourceDetails: Details of the created resource
Flow:
Client Initiates Request:
The client sends a POST request to /data/_create endpoint with action: validate.
Validation of Request:
Resource Details Validation:
Check if request.body.ResourceDetails exists and is not empty.
Throw a validation error if missing or empty with the message "ResourceDetails is missing or empty or null".
Schema Validation:
Validate request.body.ResourceDetails against createRequestSchema.
Hierarchy Type Validation:
Validate hierarchyType in request.body.ResourceDetails using validateHierarchyType function.
Tenant ID Validation:
Ensure that request.body.ResourceDetails.tenantId matches request.body.RequestInfo.userInfo.tenantId.
Throw a validation error if they do not match with the message "tenantId is not matching with userInfo".
Different Tab Headers Validation:
Validate whether headers are according to the template across all tabs of different districts.
Target Sheet Validation:
All validations will be on Sheets other than the ReadMe Sheet and Boundary Data Sheet.
Immediate validations:
District Tabs Validation:
Validate whether all district tabs are present in the Target Sheet uploaded.
Empty Sheet Validation:
Throw a validation error if any Target Sheet is empty.
Root (District) level boundary validation:
Throw a validation error if the root column (District) is empty in any row.
Validations for each row:
Boundary Codes Validation:
Check for missing or empty boundary codes in any row of any sheet.
Check for boundary code columns to be of type string.
Check for the presence of more than one boundary code in a given row of a given Target Sheet.
Check for duplicacy of the boundary code within the given Target Sheet.
Boundary Targets Validation:
Ensure that Target values are not missing and are positive numbers less than 1 Million.
Below are the configurations needed for successfully setting up the campaign module:
citymodule needed to run campaign module in an environment:
Link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-QA/data/mz/tenant/citymodule.json
roleactions config needed for the user for all campaign access
actionTest config needed for sidebar action and user access for services
To enable action in the sidebar, add navigationUrl and path to the object:
Refer to the below ID's link in QA:
roles need to be added in roles
Boundary Schema config needs to be added for boundary sheet validation:
Facility Schema config needs to be added for facility sheet validation:
User schema config needs to be added for user sheet validation:
A hierarchy config needs to be added to define a lowset hierarchy in boundary selection:
Global configuration needs to be added to environments.
Helm chart needs to be added in DevOps.
Refer here to learn more about the setup environment.
rainmaker-common
For all common screen localisation messages like login, homepage, sidebar
rainmaker-campaignmanager
For all console-related screens localisation messages
rainmaker-hcm-admin-schemas
For all upload schemas like target, facility, user
boundary-${BOUNDARY_HIERARCHY_TYPE}
For boundary type localisations, we get this BOUNDARY_HIERARCHY_TYPE from the MDMS
Generate API for Boundary by using GeoJsons
Generation API for Boundary
Base URL: project-factory/v1/
Endpoint: /data/_generate
Method: POST
Request Structure:
Body Parameters:
RequestInfo: Object containing RequestInfo
Query Parameters:
tenantId: Tenant
type: Type of Resource (e.g., boundaryManagement)
forceUpdate: Boolean type (either true or false)
hierarchyType: Name of Boundary Hierarchy
campaignId: default (Mandatory)
Success Response:
In this API the filestore ID will be the ID the geoJson file which will be:
Client Initiates Request:
The client initiates a dataGenerate request to the Project Factory Service.
Validation of Request:
Schema Validation: Validate against generateRequestSchema.
Tenant ID Validation: Ensure tenantId matches in query and RequestInfo.userInfo.
Force Update: Default to "false" if missing.
Hierarchy Type Validation: Validate hierarchyType for the tenantId.
Processing of Generate Request:
Fetch Data from DB:
Retrieve data using getResponseFromDb(request).
Modify Response Data:
Modify the fetched data with getModifiedResponse(responseData).
Generate New Entry:
Create a new entry with getNewEntryResponse(request).
Expire Old Data:
Update the status of old data to expired using getOldEntryResponse(modifiedResponse, request).
Persist Data Changes:
Call updateAndPersistGenerateRequest(newEntryResponse, oldEntryResponse, responseData, request).
Purpose:
If forceUpdate is true and data exists: Mark existing data as expired and create new data.
No data exists or force update is true: Generate new data.
If forceUpdate is false and data exists: Return the old data.
Boundary Data Processing:
Generate new Boundary Data:
Fetch Boundary Relationships.
If no boundary is found, generate an empty boundary sheet.
Fetch Filters from CampaignId and generate Boundary Data based on those filters.
If the filter is null, it will generate the whole Boundary Data.
After the Boundary Sheet has been generated, append the ReadMeSheet.
Generate different tabs based on any boundary level configured (here District).
Generating Different Boundary Templates based on Campaign Type
Fetch configurable columns from mdms present for each campaign type from schema - (HCM-ADMIN-CONSOLE.adminSchema).
Here is a sample data from the given schema having configurable columns for the SMC campaign:
Handle Error:
Update status to failed, add error details, log the error, and produce a message to the update topic.
Downloading the generated boundary template through /data/_generate API:
One can get the filestoreId through the /data/_download API which will fetch from db using the id from the response of /data/_generate API.
After successful generation, the sheet you will get from filestoreId will be:
Note: The downloaded template will have one ReadMe sheet, one Boundary Data tab, and all other tabs on a number of unique districts (or whichever level is configured).
The documentation details APIs for creating, searching, generating, and downloading data, including request/response structures, flows, and error handling.
Endpoint: /data/_create
Method: POST
Body Parameters:
RequestInfo: Object containing request information.
Resource Details: Object containing the details of the resource to be created or validated.
type: Type of resource (boundary, facility, user, boundaryWithTarget).
tenantId: Tenant identifier.
fileStoreId: File store identifier.
action: Action type (create or validate).
hierarchyType: Type of hierarchy.
campaignId: Campaign identifier.
additionalDetails: Additional details object (optional).
Success Response:
- ResponseInfo: Object containing response information.
- ResourceDetails: Array containing the detail objects of the created or validated resource.
Client Initiates Request: The client sends a createData request to the Project Factory service.
Validation of Request: The Project Factory service validates the request schema and the provided resource details.
Processing the Request:
If action is 'create':
Enrich resource details, set status to "data-accepted", and persist in the database.
Further creation process happens in the background.
After successful creation, set the status to 'completed' and persist resource details in the database.
If action is 'validate':
Enrich resource details, set the status to "validation-started", and persist in the database.
Further creation process happens in the background.
If file data is invalid, set the status to 'invalid' and persist in the database.
After successful creation, set the status to 'completed' and persist resource details in the database.
Fail case: If validation or creation fails, set the status to 'failed' and persist in the database with the error cause in additional details.
Response: The Project Factory service sends the response back to the client containing the resource details and status.
The getSheetData function retrieves and processes data from an Excel sheet, validating the structure according to the configuration provided in createAndSearchConfig. The key part of this process is the parseArrayConfig.parseLogic configuration, which specifies how to parse and validate the columns in the sheet. Here's a detailed explanation of how the function works, including the parsing logic:
The parseArrayConfig.parseLogic configuration specifies how each column in the sheet should be processed. Here's how the parsing logic works:
Each column configuration specifies:
sheetColumn: The column letter in the sheet.
sheetColumnName: The expected name of the column in the sheet.
resultantPath: The path where the value will be stored in the resultant JSON.
type: The expected type of the value (e.g., string, number, boolean).
conversionCondition: Optional conditions for converting values.
During the validation step, the function checks that the first-row value matches the expected column name.
When mapping the rows to JSON, the function uses the resultantPath to place the values in the correct location in the JSON object. It converts values according to the specified type and conversionCondition.
For a column configuration with type: "boolean" and conversionCondition, the function would convert "Permanent" to true and "Temporary" to an empty string.
In summary, the getSheetData function retrieves and processes data from an Excel sheet, validating the structure and content according to the createAndSearchConfig configuration. The parseArrayConfig.parseLogic configuration specifies how each column should be validated and processed into the resultant JSON format.
Endpoint: /data/_search
Method: POST
RequestInfo: Object containing request information.
SearchCriteria: Object containing search criteria.
id: (Optional) ID of the resource.
tenantId: Tenant identifier.
type: (Optional) Type of the resource (boundary, facility, user, boundaryWithTarget).
status: (Optional) Status of the resource.
ResponseInfo: Object containing response information.
ResourceDetails: Array containing the details object of the searched resource.
Client Request: The client sends a POST request to /data/_search.
Request Content: Includes RequestInfo and SearchCriteria.
Validation: The server validates request structure and content.
Response Creation: The server creates a response with info and resource details.
Response Dispatch: Sends response back to client.
Error Handling: If errors occur, generate an error response and send it.
Endpoint: /data/_generate
Method: POST
RequestInfo: Object containing request information.
Query Parameters:
type: Type of the resource for which data needs to be generated.
tenantId: Tenant identifier.
hierarchyType: Type of hierarchy.
forceUpdate: (Optional) Boolean indicating whether to force update existing data.
ResponseInfo: Object containing response information.
GeneratedResource: Array containing the details object of the generated resource.
Client Request: The client sends a POST request to /v1/data/_generate.
Request Validation: Aftern receiving the request, the server validates the request structure and parameters.
Generate Data Process:
Validation: The server validates the generated request.
Data Processing:
Fetch Data: Fetches existing data from the database.
Modify Data: Modify the retrieved data as necessary.
Generate New ID: Generates a new random ID and sets the file store ID to null.
Expire Old Data: Marks existing data status as expired.
Generate New Data: Generates new data based on the request parameters.
Update and Persist: Updates and persists the generated request along with the new data.
Force Update Logic:
If the forceUpdate parameter is set to true:
Search and Update: Searches for existing data of the specified type and updates the existing data information.
If the forceUpdate parameter is not provided or set to false:
Fetch Existing Data: Retrieves already persisted data from the database of the specified type.
Response Creation: After processing the request, the server creates a response containing the details of the generated resource.
Response Dispatch: The server sends the generated response back to the client.
Error Handling: If errors occur, generate an error response and send it.
Fetch Required Columns from MDMS:
Use callMdmsData to get type schema columns in the correct order.
Define Headers:
MDMS schema required columns are headers and ensures column orders.
Localise Headers:
Use getLocalizedHeaders with localizationMap.
Localise Sheet Name:
Use getLocalizedName with localizationMap and generate a sheet.
To add a new column to the Generated sheet, follow these steps:
Search Schema Details
Locate the type schema from the HCM-ADMIN-CONSOLE.adminSchema schema in the workbench.
Identify Column Type
Determine the column type based on the properties defined in the schema:
stringProperties for string-based columns.
numberProperties for numeric-based columns.
enumProperties for enumerated columns.
Define New Column
Add the new column to the schema under the appropriate properties section:
String Column: Include attributes such as name, type, maxLength, minLength, isUnique, isRequired, description, and orderNumber.
Number Column: Include attributes such as name, type, maximum, minimum, isRequired, description, orderNumber, and errorMessage.
Enum Column: Include attributes such as name, enum, isRequired, description, and orderNumber.
Ensure Column Uniqueness
Ensure that the isUnique property is correctly set for string columns to enforce uniqueness.
Column Visibility (Future Implementation)
Note that hideColumn and freezeColumn features will be implemented in the next version.
This process is sufficient for validating the new column in the generated sheet.
If there's a need to reflect the column in APIs, follow these additional steps:
Update createAndSearch.ts File
Modify the createAndSearch.ts file under the defined type parseLogic object.
Integrate the new column into the appropriate data structures used for API operations.
Example :
sheetColumn: A
sheetColumnName: HCM_ADMIN_CONSOLE_FACILITY_CODE
resultantPath: id
type: string
Mapping: Data from column A (HCM_ADMIN_CONSOLE_FACILITY_CODE) in the sheet will be mapped to id in the API data.
By following these steps, you can successfully add and validate a new column in the generated sheet and ensure its reflection in the associated APIs.
General Rules
Locked Headers: The headers in the templates for each data type (user, facility, target) are locked and cannot be changed.
Sheet Protection: Certain sheets within the templates will have specific locked areas to ensure data integrity.
README Sheet: Each type of template includes a README sheet which is read-only and locked.
Target Template
Editable Columns: You can only modify the 'Target' column. All other columns are locked and cannot be edited.
Facility Template
Adding Rows: You are allowed to add new rows to create new facilities.
Editable Columns: You can modify the "Boundary Code" and 'Usage' columns.
Locked Sheets: The boundary data sheet within the facility template is locked and cannot be modified.
Dropdown Columns: The following columns are dropdowns:
Facility Type
Facility Status
Facility Usage
Facility Usage: Facility usage can be 'Active' or 'Inactive'. Active facilities are used in the campaign and require a boundary code to map.
User Template
Adding Rows: You are allowed to add new rows.
Locked Sheets: The boundary data sheet within the user template is locked and cannot be modified.
Dropdown Columns: The following columns are dropdowns:
Role
Employment Type
Data for Dropdowns
The data for the dropdown columns comes from the mdms (Master Data Management System) under the adminSchema master.
Endpoint: /data/_download
Method: POST
RequestInfo: Object containing request information.
Type: (Optional) Type of the resource being downloaded.
TenantId: Tenant identifier.
HierarchyType: Type of hierarchy.
Id: (Optional) ID of the resource being downloaded.
Filters: (Optional) Additional filters for the download request.
campaignId : campaignId
ResponseInfo: Object containing response information.
ResourceDetails: Array containing the details object of the downloaded resource.
Client Request: The client sends a POST request to download data.
Request Validation: Upon receiving the request, the server validates the request structure and parameters.
Data Download Process:
Validation: Validate the download request.
Fetch Data: Fetch existing data of the specified type from the data host service.
Processing: Process the retrieved data as necessary.
Response Creation: After processing the request, the server creates a response containing the details of the latest resource, ensuring that only one result is fetched.
Response Dispatch: The server sends the generated response back to the client.
Error Handling: If errors occur during the process, an error response is generated and sent.
If the downloaded response is empty or not searched with the provided ID, the system automatically starts regenerating a template of the same type. The generation process is triggered by the backend, not through the UI.
Overview:
In the Campaign Details section, there are 4 screens:
Campaign Type
Campaign Name
Campaign Dates
Campaign Details Summary
This is the first screen when the user clicks on "set-up campaign". In this screen, the user can select the campaign type, and the beneficiary will be prepopulated from the MDMS. This field is mandatory to set up a campaign.
Here, the dropdown will show the list of campaign types in the MDMS. We will fetch the MDMS data from, for more information you can check on configurations from the link here
This screen comes after the campaign type. This step is crucial for saving your campaign as a draft, as the name serves as a unique identifier. After clicking on 'Next', the name will be saved and the user can check from the draft.
This screen asks a user to fill in the start and end dates of the campaign.
This screen will show the summary of the campaign details screen
project-factory/v1/project-type/create
CAMPAIGN_MANAGER
project-factory/v1/project-type/search
CAMPAIGN_MANAGER
/project-factory/v1/project-type/search
CAMPAIGN_MANAGER
/project-factory/v1/project-type/update
CAMPAIGN_MANAGER
In this step, the user will encounter 2 screens:
Boundary Details
Boundary Details Summary
This screen allows users to select the boundaries according to their requirements.
The working of this screen is as follows:
We will fetch the boundary data according to the hierarchy saved in the MDMS.
The file where data is fetched - https://github.com/egovernments/DIGIT-Frontend/blob/console/health/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/Module.js
The hierarchy structure and the lowest boundary will be fetched from the MDMS
For more information on the master data can be referred here
This screen will be shown using the component
Which internally calls the - Selecting boundary component
Validation: The user must select boundaries till the lowest level. If the parent boundary is selected, then the user should select at least one of its child.
This screen displays all the boundaries selected in the previous step.
Boundary localisation for this screen happens by using the combination of hierarchy type and boundary type
It should be in this format.
boundary-service/boundary-relationships/_search
CAMPAIGN_MANAGER
/boundary-service/boundary-hierarchy-definition/_search
CAMPAIGN_MANAGER
The summary screen provides users with a view of all campaign details entered.
Users can review the entirety of their campaign information. If the campaign status is marked as 'drafted,' users can either edit the existing data or submit it. After submission, the campaign is created, initiating the 'create' action.
For campaigns in a 'draft' status, the summary screen serves as the final step of the campaign setup process, giving users the option to edit or submit the details before finalisation.
If the campaign is successfully created while in the 'draft' status, users are directed to a success screen.
After the API call, the data undergoes restructuring to present delivery rules based on the cycle and delivery details.
For draft status only:
/project-factory/v1/project-type/update
CAMPAIGN_MANAGER
For IRS to be displayed as the campaign type , initially it needs to added in the MDMS. Master name: projectTypes Module name: "HCM-PROJECT-TYPES" https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/project-types.json
Changes in delivery details:
The delivery configuration in the MDMS needs to be updated. The desired properties will show the attributes, operator, and value.
For the IRS campaign type, the number of cycles and the number of deliveries will not be editable.
To make the cycle and deliveries not editable, we need to pass one flag in the delivery configuration.
The delivery conditions page will be shown like this in which values will come from the MDMS.
Master name: HOUSE_STRUCTURE_TYPES
Module name: HCM
For the target templates to be generated dynamically, data needs to be added in the adminSchema.
The resource upload details consists of 3 types of uploads:
Upload Target Data
Facility Upload
User Upload
Upload Summary
This screen will come after a user selects the boundaries.
When a user clicks on the download template button, an Excel will get downloaded which will contain readMe, Boundary Data sheet along with the sheets with districts, where the user has to fill the target at the lowest level. After the file is uploaded, it will go for validation. Once validated, a user can go to the next page, where the user can delete the file and move to the next page to upload facility date.
This screen will come after the target upload screen.
In this screen, when a user clicks on the download template, an Excel gets downloaded containing readMe, Facility sheet, and BoundaryData sheet. A user has to fill in the boundary codes and from that sheet, the user has to fill in the facility sheet.
This screen will appear after the facility details screen.
When a user clicks on the download template, an Excel file gets downloaded that consists of readMe, User Sheet, and BoundaryData. The user has to fillout the user sheet only.
All the 3 downloads are happening through the Generate and Download APIs. For the Generate API, the following hook is used: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/hooks/useGenerateIdCampaign.js
This hook will return the ID which is stored in the local storage according to the type:
Next, /project-factory/v1/data/_download is used to download the template.
This screen displays all the files which were uploaded in the previous screens, Validation in this screen -
All the 3 files are mandatory to upload in this step otherwise the user is not allowed to move to the next step.
After uploading the templates, UI validation is done through schema stored in the MDMS: Schema Data link: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/hcm-admin-console/adminSchema.json
Schema Module = adminSchema Below is the admin schema-
By using AJV Validation , we are validating the headers of the facility sheet. We are also doing some basic validations for the data such as-
Facility Type can only be Warehouse/Health Facility
Facility Name can only be string
Facility Status can only be Temporary or Permanent etc.
Apart from this, we are also validating sheet names in all the 3 uploads.
For target validation, we use schema only for validating the header of the target and boundary codes. Here, we also validate the target at the lowest level, where the value should be between:
Before calling we are using base time out which is fetched from the MDMS
For more information on this schema, you can refer to:
For the backend validation, we use the following hook: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/hooks/useResourceData.js
The screens are using the given below components for upload and validation-
Preview component: https://github.com/egovernments/DIGIT-Frontend/blob/campaign/micro-ui/web/micro-ui-internals/packages/modules/campaign-manager/src/components/XlsPreview.js
/project-factory/v1/data/_download
CAMPAIGN_MANAGER
Params will be different for different types- 1) boundary tenantId:mz
type:boundary
hierarchyType:ADMIN
id:987eadc3-55a0-4553-925d-bf8087f57e5a 2) facilityWithBoundary tenantId:mz
type:facilityWithBoundary
hierarchyType:ADMIN
id:052f59fc-18a7-4e07-816a-f5d8062b56b5 3) userWithBoundary tenantId:mz
type:userWithBoundary
hierarchyType:ADMIN
id:fbfbd393-d053-4f51-9e12-1068b97da292
/project-factory/v1/data/_create
CAMPAIGN_MANAGER
1) type: boundaryWithTarget { "type": "boundaryWithTarget", ""action": "validate",
"campaignId": "13175791-db53-4d10-be90-2dba1c138756" }
2) type: facility { "type": "facility",
"action": "validate",
"campaignId": "13175791-db53-4d10-be90-2dba1c138756"}
3) type: user { "type": "user",
"action": "validate",
"campaignId": "13175791-db53-4d10-be90-2dba1c138756" }
A new pop-up has been added which displays the option to download the template in all three upload screens.
Use Case:
when the user comes after clicking next on the delivery screen and the file is not uploaded then this pop-up is displayed.
A new 'Actions' column has been added to the "My Campaign" screen, allowing users to perform some tasks skillfully.
Users can click on 'Actions' to choose from the available action options in the menu.
We've added config for column actions in myCampaignConfig.js
In UICustomization.js, we have added a component that needs to be rendered for the action column under additionalCustomizations.
We have added an onActionSelect function which acts based on the selected option.
Actions are different according to the different campaign status
Here user will get all the actions such as:
For the case of ongoing campaigns user is able to update the campaign , configure checklist and to view user credentials , all the 4 options will be visible.
For the case of completed campaings user will not be able to update the campaign. Only view the user credentials:
Here user will get all the actions such as: For the case of upcoming campaigns user is able to update the campaign , configure checklist and to view user credentials ,all the 4 options will be visible.
Draft state will have no action button.
Failed state will have no action button.
File Path:
Config:
UICustomisation:
The timeline provides a visual representation of the campaign creation process. It can be accessed from the summary or through the action button on the "My Campaign" screen. The timeline will be shown for ongoing, upcoming, completed, and failed campaigns.
This timeline shows all the stages of the campaign that are successfully created. A user can download the user credentials as soon as the campaign is created successfully.
The above images show all three timeline steps: upcoming, current, and completed.
A user can also access the timeline from the "My Campaign" screen by clicking on the action button present in the search result.
The timeline will be shown as a pop-up from the "My Campaign" screen. Similar to the summary, while the campaign creation is in progress, it will display all the steps such as upcoming, current, and completed. User credentials will be downloaded once the campaign is successfully created.
/project-factory/v1/project-type/getProcessTrack
POST
params: { campaignId: campaignId, },
This flow allows the user to update campaign boundary, facility, user, and target details once the campaign is created.
Users can go to update campaign flow from the action button present in my campaigns screen.
Updating the campaign is possible only for ongoing and upcoming campaigns.
Screens coming for this update campaign are-
Selecting Boundary
Update Facility details
Update User details
Update Target
Summary
This is the first screen that is displayed to the user when they try to update the campaign from the My Campaigns screen. This screen is already pre-filled with the boundary data which is selected during the campaign creation.
It is impossible to delete the already selected boundaries, user can always add new boundaries if they want to update.
This screen allows the user to update the facility details:
When the user downloads the current facility template, then that template is already filled with the facility details that the user has entered during the time of campaign creation.
In this user can add the new facilities.
This screen allows the user to update the facility details:
When the user downloads the current user template, then that template is already filled with the user details that the user has entered during the time of campaign creation.
In this user can add a new user.
This screen allows the user to update targets:
When the user downloads the current target template then that template is already filled with the target details that the user has entered during the time of campaign creation.
In this user can add the new targets or change the existing ones.
The file path of all the upload screens:
This helps the user to view the summary of all the entered details in the previous screens:
The update campaign flow works similarly to the setup campaign. But the difference is that here we send the parentId in the URL and fetch it from there.
When the user clicks on next after the boundary details screen, the create API is called with parentID in the params and with action = draft. Then for the subsequent steps update API is called. In the summary screen again create API is called again but with action = 'create'. This action updates the campaign.
If no new boundary selected - If the user has not selected any new boundary then, to update the campaign at least one data upload is necessary.
New Boundaries Added - If the user has selected new boundaries then all the 3 data uploads are necessary for the user.
/project-factory/v1/project-type/create
CAMPAIGN_MANAGER
"action": "draft", "action": "create", to update the campaign
/project-factory/v1/project-type/search
CAMPAIGN_MANAGER
only id is required in params
/project-factory/v1/project-type/update
CAMPAIGN_MANAGER
/project-factory/v1/data/_download
CAMPAIGN_MANAGER
Params will be different for different types- 1) boundary tenantId:mz
type:boundary
hierarchyType:ADMIN
id:987eadc3-55a0-4553-925d-bf8087f57e5a 2) facilityWithBoundary tenantId:mz
type:facilityWithBoundary
hierarchyType:ADMIN
id:052f59fc-18a7-4e07-816a-f5d8062b56b5 3) userWithBoundary tenantId:mz
type:userWithBoundary
hierarchyType:ADMIN
id:fbfbd393-d053-4f51-9e12-1068b97da292
This screen enables users to update the start date, end date, and cycle dates for both ongoing and upcoming campaigns. Additionally, an 'Actions' column has been added to the "My Campaign" screen, providing more options for managing the campaigns.
When a user clicks on 'Actions', they will see the "Update Dates" option. Selecting "Update Dates" redirects the user to the update date screen.
We have added an MDMS configuration flag to determine whether the dates can be updated with or without boundaries. Depending on the MDMS flag, the appropriate screen will be rendered.
If the MDMS flag for updating dates with a boundary is set to true, the corresponding screen for updating dates will be rendered.
If the MDMS flag for updating with a boundary is set to true, the corresponding screen will be rendered. On this screen, the user first selects the hierarchy level and boundary they wish to update. After making their selection, the user clicks the 'Confirm' button.
Based on the selected boundaries, the corresponding dates are displayed. The user can then change the dates and cycle dates as needed. Fields with dates that have already passed (relative to today) are made non-editable.
After making the desired changes, the user clicks the 'Confirm' button to update the dates. Once the update is successful, a success response screen is shown, and the user is redirected back to the "My Campaign" screen.
If the MDMS flag is set to false, the corresponding screen is rendered to update the dates without considering boundaries, at the root level.
When the user clicks on "Update Date" for the respective campaign, the update date screen is shown with all the prefilled start and end dates. The user can then make the necessary changes.
The user can change the editable dates. Any date fields that have passed the current date are non-editable. Once the user confirms the date change, the data is updated. After a successful update, the user is redirected to a success screen.
MDMS configuration to check whether the update date is at the root level or boundary level: https://github.com/egovernments/egov-mdms-data/blob/UNIFIED-DEV/data/mz/health/hcm-admin-console/dateWithBoundary.json
MDMS Link:
/health-project/v1/_search?tenantId=mz&limit=10&offset=0
CAMPAIGN_MANAGER
/health-project/v1/_update
CAMPAIGN_MANAGER
/health-project/v1/_search?tenantId=mz&limit=10&offset=0
CAMPAIGN_MANAGER
/health-project/v1/_update
CAMPAIGN_MANAGER
boundary-service/boundary-hierarchy-definition/_search
CAMPAIGN_MANAGER
Following is the procedure to configure default templates for checklists for different roles and types of checklist.
Following is the curl to create a template for:
The user needs to create a template for all the combinations of roles, campaign types, and checklist types for which he/she wants to have a checklist configured.
If any option needs to have sub-questions, then add an optionDependency attribute as true in the option's object. All the questions, whether at the parent or children level, need to be different objects and connected via their parentId which is nothing but the parent option's ID.
The question object is represented as a JSON structure with the following key properties:
id (String, Required)
A unique identifier for the question.
Example: "2d4a7b1e-1f2f-4a8a-9672-43396c6c9a1c"
key (Integer, Required)
The question's sequence or order in the questionnaire.
Example: 1
type (Object, Required)
Represents the type of the question.
Contains a code field to specify the question type.
Example: { "code": "SingleValueList" }
level (Integer, Required)
Indicates the hierarchy level of the question.
Example: 1 (Top-level question)
title (String, Required)
The text or content of the question.
Example: "Is there a feedback system for health facilities to report any issues or requests related to bednet distribution?"
value (String/Null, Optional)
Holds the selected value once a choice is made.
Initially null.
options (Array of Objects, Required)
A list of predefined choices for the question.
Each option includes:
id: Unique identifier for the option.
key: Sequence/order of the option.
label: Text describing the option.
optionComment: (Boolean) Indicates if a comment is allowed for the option.
optionDependency: (Boolean) Indicates if selecting the option triggers a dependent question.
parentQuestionId: Links the option to its parent question.
Example:
isActive (Boolean, Optional)
Indicates whether the question is active or visible in the form.
Example: true
parentId (String/Null, Optional)
Specifies the parent question ID if the question is a subquestion.
Example: null for top-level questions.
isRequired (Boolean, Optional)
Indicates if answering the question is mandatory.
Example: false
The question object is represented as a JSON structure with the following key properties:
id (String, Required)
A unique identifier for the question.
Example: "23ca54be-038e-42df-a557-bb5fcd374dd5"
key (Integer, Required)
The question's sequence or order in the questionnaire.
Example: 3
type (Object, Required)
Represents the type of the question.
Contains a code field to specify the question type.
Example: { "code": "MultiValueList" }
level (Integer, Required)
Indicates the hierarchy level of the question.
Example: 1 (Top-level question)
title (String, Required)
The text or content of the question.
Example: "What services or products do you distribute to health facilities?"
value (Array/Null, Optional)
Holds the selected values once options are chosen.
Initially null.
options (Array of Objects, Required)
A list of predefined choices for the question.
Each option includes:
id: Unique identifier for the option.
key: Sequence/order of the option.
label: Text describing the option.
optionComment: (Boolean) Indicates if a comment is allowed for the option.
optionDependency: (Boolean) Indicates if selecting the option triggers a dependent question.
parentQuestionId: Links the option to its parent question.
Example:
isActive (Boolean, Optional)
Indicates whether the question is active or visible in the form.
Example: true
parentId (String/Null, Optional)
Specifies the parent question ID if the question is a subquestion.
Example: null for top-level questions.
isRequired (Boolean, Optional)
Indicates if answering the question is mandatory.
Example: false
The parent question object (SingleValueList) has the following properties:
id (String, Required)
A unique identifier for the question.
Example: "4add5323-fc98-4e71-a783-27dbb922c99f"
key (Integer, Required)
The order or sequence of the question.
Example: 2
type (Object, Required)
Indicates the question type.
Example: { "code": "SingleValueList" }
level (Integer, Required)
Denotes the hierarchy level. For parent questions, this is 1.
Example: 1
title (String, Required)
The content of the question.
Example: "What types of health facilities do you distribute to?"
value (String/Null, Optional)
Holds the selected value after a user chooses an option.
Initially null.
options (Array of Objects, Required)
A list of predefined choices, where:
optionDependency: Determines if selecting the option triggers a nested question.
Example:
isActive (Boolean, Optional)
Specifies whether the question is active.
Example: true
parentId (String/Null, Optional)
null for top-level (parent) questions.
isRequired (Boolean, Optional)
Indicates if the question is mandatory.
Example: false
Structure of Nested Question
The nested question object is similar to the parent question but includes additional context linking it to the triggering parent question.
id (String, Required)
Unique identifier for the nested question.
Example: "c65ac34b-7cc0-4993-a8fe-37e854d2b189"
key (Integer, Required)
Sequence/order of the question.
Example: 4
type (Object, Required)
Specifies the type of question.
Example: { "code": "SingleValueList" }
level (Integer, Required)
The hierarchy level. Nested questions have a higher level (e.g., 2).
Example: 2
title (String, Required)
The text of the nested question.
Example: "Do you have enough products for distribution to health facilities?"
value (String/Null, Optional)
Holds the selected value after a user chooses an option.
Initially null.
options (Array of Objects, Required)
The predefined choices for the nested question.
Example:
isActive (Boolean, Optional)
Indicates whether the question is active.
Example: true
parentId (String, Required)
Links the nested question to the triggering parent option.
Example: "23ace43b-e0b5-428f-9d11-12fc5b10b1ac1"
isRequired (Boolean, Optional)
Specifies if the nested question is mandatory.
Example: false
