About HCM Console

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.

Key Features

Version 0.2 focuses on empowering users to do the following:

• Initiate campaigns: A clear landing page will provide easy access to the "Setup Campaign" and "My Campaign" options.

• Define campaign details: A dedicated page will allow users to customise crucial campaign parameters.

• Set delivery rules: Users can establish delivery rules, including options to record side effects, reasons for refusal, and referrals.

• Utilise Excel data: An upload functionality will enable seamless import of facility and user data from Excel sheets.

• Review and confirm: Clear review and success screens will guide users through the final steps of campaign creation.

• Save drafts: Users can conveniently save incomplete campaigns as drafts for completion later.

These features, cumulatively, will allow users to create the core structure of their campaigns within version 0.2. 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.

Overview

We have introduced a new service project-factory and console web to streamline the campaign setup process

Project Factory

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),

Console

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.

Overview

This release will let the user - who is a System Administrator - set up campaigns on the HCM App and will reduce the current setup time for a given campaign from about 15 days to about 2-3 days

Release Highlights

Known Issues

Some of the known issues related to this release are:Comment

1. 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

Upcoming Release Features

1. Decentralising the data setup process.

2. Changing dates for ongoing campaigns from the Console.

3. Allowing users to configure app features.

Table of Contents:

Background

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.

Target Audience

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.

Objectives (of this release)

1. Reduce set-up time for new campaigns.

2. Reduce dependence on engineering resources for setting up a new campaign.

3. Provide the power to the end user for customising campaigns.

Assumptions and Validations

Role-Action Mapping

Specifications

Risk and Limitations

1. Boundary data: If the boundary data is updated regularly, then the analytics for the long-term will not have data sanity.

2. Users might have issues uploading multiple Excel sheets for targets, facility, and user data.

Out of Scope for v0.1:

1. 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.

2. 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.

3. Language selection for the app will not be a part of this release.

Design

Here are the articles in this section:

v0.1 Release Notes

Overview

This release will let the user - who is a System Administrator - set up campaigns on the HCM App and will reduce the current setup time for a given campaign from about 15 days to about 2-3 days.

Release Highlights

Known Issues

Some of the known issues(Change Requests have been created) related to this release are:

1. Redirecting user from Date change confirmation screen to "Campaign Summary" screen

2. Seeing updated dates on Campaign Summary screen

Upcoming Release Features

1. Allowing users to configure app features (Checklist).

2. Allowing users to update the Ongoing Campaign Data

The HCM Console will help admins set up a campaign on the DIGIT HCM App. This will help an admin reduce the campaign setup time which is about 15 days (without the console) to less than 3 days to less than 3 hours (with the console). Further, v0.1 of HCM Console will also aim at reducing the dependencies on the implementation team for setting up campaigns and campaign data on the DIGIT HCM app and provide this capability directly to the end user.

Key Features

Ability to set up a campaign with the following features:

• Homepage with Setup Campaign and My Campaign call-to-action buttons

• Campaign details page

• Boundary details

• Delivery details

• Excel upload for targets, facility, and user data setup

• Review and success screens

• Ability to save campaigns as draft

User Role

Who can use the HCM Console?

User Flow: Steps to Use HCM Console

Select the language before logging in. Currently, 3 languages are supported for the HCM Console. They are:

• English

• Portuguese

• French

Select the preferred language and click on Continue to go to the login page.

(Note: Getting an account on HCM Console: The admin will have their account created by the implementation team and will be provided with a username and password to log in to the account.)

On the login page, input the User Name, Password, and the applicable City to log in to HCM Console.

Once you log in, follow the steps below to set up a campaign using the HCM Console or view the ones already set up:

Homepage (Setup Campaign and My Campaign): After logging in, you will see 2 actions you can perform on the homepage - My Campaigns and Setup Campaigns.

My Campaign

Click on My Campaign to view existing campaign details. This will show -

a. A list of all the campaigns that the admin has created until now for future dates, past dates, or current dates, including drafted campaigns. The campaigns are listed and grouped under 5 status tabs depending on its existing status. These tabs are:

1. Ongoing

2. Completed

3. Upcoming

4. Drafts

5. Failed

b. There are 5 columns for each campaign:

1. Campaign Name

2. Campaign Type

3. Beneficiary Type

4. Campaign Start Date

5. Campaign End Date

If you click on the name of the campaign, you will be redirected to the summary page.

Setup Campaign

If you click on “Setup Campaign” you will see the basic Campaign Details page. There are 7 actions you can perform when you click on Setup Campaign:

1. Campaign Details

2. Boundary Details

3. Delivery Details

4. Target Details

5. Facility Details

6. User Details

7. Summary.

Each action and its steps are explained below:

1. Campaign Details

On the Campaign Details page, you will see a list of questions which you will have to answer:

Which is the type of campaign you want to run? (This is a mandatory field for moving to the next screen).

This question will allow you to select any one of the preloaded campaign types. If there are campaigns that are not there in the list, they will first need to be added from the backend with data that has been agreed upon by stakeholders. Based on the selected campaign, the following data will be prefilled in the next steps:

1. Beneficiary Type (Campaign details step)

2. Number of Cycles and Deliveries in each Cycle (Delivery step)

3. Product delivered in each delivery for each cycle based on the corresponding delivery parameters (Age, Weight, Height, Gender) (Rule Engine Step)

Once you select the campaign type, click on 'Next'.

What is the name of your campaign? (This is a mandatory field for moving to the next screen): The answer to this question will be used as the name of the campaign for the reference purpose of the user.

(Note: The campaign will automatically be saved as a draft once you provide a unique name for the campaign.)

Note: The campaign setup of the types of campaign will same expect from the delivery details. And Target template will also come according to the type of the campaign.

Once you enter the "Name of the Campaign", click on 'Next'. You will move on to the Boundary Details page.

2. Boundary Details

This step will enable you to select the existing boundary data in the system. (This is a mandatory field for moving to the next screen). The boundary data will have to be set up in the system beforehand at the time of instance creation and the same boundary data should be reused by the user for all campaigns in a given instance.

(Note: If you have not selected boundaries, you will not be allowed to move on to the next steps. For example: If the boundary data is set up for Mozambique, the user will see the whole boundary mapping for Mozambique that is available on the system. If there is a need for change, we will provide the contact information for the L1 team to update the boundary and the L1 team will update the boundary data.)

The boundary selection for a campaign will happen through a mapped checkbox field as shown below. There is a drop-down-based selection for each level of the hierarchy:

(Note: If a given boundary is selected in one level of the hierarchy, the next level will show boundaries mapped to only the ones selected in the previous level. You will not be able to make any selection at a given level without selecting the boundaries in the level above. If you are creating a new boundary data by raising a request with the L1 team, the UI will have only the updated boundary hierarchy type.)

After you have selected the country, province, district, and post administrative, click on ‘Next’. This will take you to the Delivery Details page for the campaign.

3. Delivery Details

On the delivery details page, you will configure the following:

1. Campaign start and end dates

2. Number of cycles and number of deliveries in each cycle of the campaign

3. Configuring dates for each cycle

4. Configuring parameters for delivery rules

5. Configuring resources for delivery

Select the start date and end date of the campaign and click on ‘Next’.

(Note: The start and end dates of the campaign will define the window in which the campaign will remain active on the system and the users of the app will be allowed to login only during the selected campaign dates.)

You will come to the screen that shows the number of cycles and deliveries in each cycle of the campaign (These are mandatory fields for moving to the next screen): You will see the number of cycles and deliveries pre-configured based on the campaign type selected by the user in the first step. If you choose to increase or decrease the number of cycles, you can do so. The maximum number of cycles and deliveries can be up to 5.

Dates for each cycle (These dates are non-mandatory for moving to the next screen): You will add the start and end dates for each cycle. If you do not add these dates, you can still move to the next screen by clicking on 'Next'.

The next page is on Configure Conditions for Delivery:

Conditions for Individual-based Campaigns:

You will see all the conditions pre-configured for the selected individual-based campaign, but you can choose to change the conditions if needed.

Based on the number of cycles and deliveries in each cycle, you will see the exact number of tabs for cycles and deliveries. If you go back and reduce the number of cycles or deliveries, the last cycle/delivery will be deleted first and all the rules will also be deleted along with it.

Selecting Attributes: After this, you will have to configure conditions using the following attributes:

• Age (in months)

• Weight (in kgs)

• Height (in cms)

• Gender (Male or Female) - When this attribute is selected, you can only select “Equals To” in the operator field and the input field should be set to Male and Female only as a single dropdown selection.

If you want to configure a condition having multiple attributes, you can click on “Add More Attributes” which will open up the selector block again.

Selecting Operators: You can choose to select the following operators to set rules:

• IN BETWEEN (if this is selected, you should see 2 input boxes for value)

• GREATER THAN

• GREATER THAN EQUAL TO

• LESS THAN EQUAL TO

• LESS THAN

• IS EQUAL TO

Configuring Resources: Once you have selected all the attributes, operators, and values basis which the deliveries have to be made, you can click on configure resources which will open a pop-up that will have the following:

• Product to be delivered

• Count for each product - This is a numeric counter only and cannot be 0.

• Add resources CTA to add multiple resources for the rule being configured.

• Can’t find your product in the list? Add New Product as subtext.

• The “Confirm Resources” button to confirm selected resources for a given rule.

If you are not able to find the product variant of your desired choice, you will be allowed to create a new product. If you click on “Can't fnd your product on the product list?”, you are redirected to a new tab where you will fill the following fields.

1. Product Name: Should be the name of the resource. (Alphanumeric with a limit of 100).

2. Product Type: Dropdown which can have the following options: Medicine, Bednet, Tonic.

3. Product Variant: Ideally this should have the grammage of the formulation (Alphanumeric with a limit of 100).

Once you have saved the new product by selecting “Confirm Addition of Products”, you will see a success message. You will also be redirected to the rule setting page, where you will see the new product added in the “Product to be Delivered" dropdown.

(Note: If the admin has added some products already (let’s say 4) and then plans on adding a new product to the list after he/she has added the new product(s) and gets redirected to the “Delivery Rules” page, the admin will still see the 4 products previously added in the pop-up.)

Conditions for Household-based Campaigns:

Currently, we only support LLIN bednet campaigns as a household-based campaign. In this case, the user will only have to configure 2 attributes:

• Number of beneficiaries per bednet

• Maximum number of bednets per household

(Note: The add new condition button for bednet campaigns will be disabled and will have only 2 attributes in the dropdown, that is, the number of beneficiaries per bednet, and the maximum number of bednets per household.)

Once you have set the delivery rules, and clicked on ‘Next’, you will move to the Target Details page.

Conditions for IRS Campaigns:

Currently for the IRS type of campaign, we are allowing user to choose the type of structure from the given drop down values, which by default is "Cement" .

4. Target Details

Here, you will set targets for the campaign by default at the lowest level of the hierarchy structure (This is a non-mandatory step for moving to the next screen). This will be achieved by an Excel upload as explained below:

To set targets, click on “Download Template” in the pop-up that appears as soon as you arrive on this screen. You will download the template with all the boundaries in Excel and an empty column for setting targets.

(Note: Each campaign will have its own target setting template: For example, the bednet campaign will have its template, and the SMC campaign will have its template, similarly for the IRS.)

The first tab/sheet will be the “Read Me” tab, which will contain information on how to set the targets for each village selected in the boundary selection screen.

The district-wise sheets will have the following structure:

Target Data Template (Bednet Campaign)

Target Data Template (SMC Campaign)

Target Data Template (IRS Campaign)

(Note: All the villages in the Excel will be listed based on the district they belong to, with one tab for each district having a list of the villages under them. For example, if you have selected 20 districts, you will see 20 tabs (one for each district) having all the villages belonging to that particular district. Target numbers assigned for a given boundary are for the complete campaign and not just for each cycle.)

Once you have uploaded the targets, click on 'Next' to move to the Facility Details page.

5. Facility Details

Setting up the facility data will include downloading and uploading the list of facilities (This is a non-mandatory step for moving to the next page):

Case 1: Facility Data is not created in the system:

• You will see a pop-up to download the Excel sheet.

• The facility Excel file will be downloaded when you click the ‘Download’ button. The template for the Excel is here.

• The Excel will have 2 sheets: 1) List of Available Facilities, 2) List of Campaign Boundaries. The second sheet will have the list of campaign boundaries with boundary codes which you can copy to the first sheet to assign boundaries to facilities.

• In the case where there is no facility data available in the facility registry, the “List of Available Facilities” sheet will have no data but will have 7 column headers to capture facility details which are:

• When there is no facility data in the system, you need to add the Facility Name (must be unique), Facility Type (Warehouse/Health Facility), Facility Status (Temporary/Permanent), Capacity (Number input), Boundary Codes which are associated with a given facility and Facility Usage Status (Active/Inactive).

• If a facility is associated with 2 or more boundaries, add all the boundary codes for that facility in the boundary code column separated by commas.

• The entry of 'Active' or 'Inactive' in the column "Facility Usage" will decide if a given facility in the registry will be used in the campaign or not. If a facility is set to "active" the facility will be used in the campaign or else it will not.

• Each facility can be assigned multiple facility types. If a given facility has multiple types, add each type separated by commas as shown here: Warehouse, Health Facility.

• The facility will be created at the hierarchical level to which the boundary code is associated. The facility to boundary code mapping shows that the facility serves these boundaries and not that it is present there physically.

• You can then upload the populated Excel sheet and move to the next step.

Case 2: Facility data exists in the system:

• You will see a pop-up to download the Excel sheet.

• The facility Excel file will be downloaded when you click on the ‘Download’ button. The template for the Excel is here.

• The Excel will have 2 sheets: 1) List of Available Facilities, 2) List of Campaign Boundaries. The second sheet will have the list of campaign boundaries.

• As there are facilities that already exist in the Facility Registry, the user will see this list of facilities in the "List of Available Facilities" sheet with all the columns in the sheet already prefilled.

• The user can set an existing facility to 'Active' or 'Inactive' under the Facility Usage Status column without changing any other column inputs for the given facility based on whether the facility will be used in the campaign or not. Any existing facility being used in a campaign should be set to active, if it is not being used in the campaign it should be set to inactive.

• When there is new facility data that needs to be added to the system, you need to add a new line item with the following columns filled out: Facility Name (must be unique), Facility Type (Warehouse/Health Facility), Facility Status (Temporary/Permanent), Capacity (Number input), Boundary Codes and Facility Usage Status (Active/Inactive).

• Once you upload the Excel sheet, click on ‘Next’ to move to the User Details page.

6. User Details

(Note: This is a non-mandatory step for moving to the next screen. The data for users will not be saved in the system and the system admin will have to keep uploading the information for users every time they create a new campaign.)

• You will see a pop-up to download the Excel sheet on this page.

• The Excel template will have 2 sheets: 1) Create List of Users, 2) List of Campaign Boundaries. The second sheet will have the list of campaign boundaries with boundary codes which you can copy to the first sheet to assign boundaries to users.

• The link to the user data upload excel is here

• The "Create List of Users” sheet will have the following column headers:

• Create a line item for every user.

• If there is a user who is mapped to multiple boundaries, the system admin will have to add the boundary codes to all the boundaries that the user is mapped to by separating them by commas.

• You must enter all columns in the given sheet as shown above, where all columns are mandatory. The username and password for each user added as a separate line item will be generated at the time when the campaign is successfully created.

• The user credentials will be created and available for download as an Excel file on the campaign details page with all the columns filled by the user and the username and credentials for each user.

Once you have uploaded the user data, click on 'Next' to go to the Summary page.

7. Summary

Once all details have been added and saved, you can see the information collected in all the previous steps on the summary page. You can click on the files attached in each step and see the preview of the file attached. You can also edit any one of those sections.

You can edit a campaign's start date if it has passed but the campaign is in the draft stage. If the campaign is created, the dates can only be changed if the campaign start date has not passed.

Once you are satisfied with all the information, click on “Create Campaign”. The success screen will show that the campaign data has been captured successfully. It will take some time to create the campaign on the system, including the user credentials.

You can click on “Go to My Campaigns” where you can view the campaign in the ‘Upcoming’ tab and click on it.

Once you click on the campaign, you will see the summary page where the user credentials can be downloaded.

Overview

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.

Pre-requisites

• 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.

Base URL

project-factory/v1/

APIs Overview

Create Campaign

TO DO add other information

DB DIAGRAM

Swagger :

Configs and helm chart details :

• Persister config : https://github.com/egovernments/configs/blob/UNIFIED-UAT/health/egov-persister/project-factory-persister.yml Helm chart details : https://github.com/egovernments/DIGIT-DevOps/blob/unified-env/deploy-as-code/helm/charts/health-services/project-factory/values.yaml

• 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.

Additional APIs being used are:

• 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

IdGen Config:

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.

{
    "format": "CMP-[cy:yyyy-MM-dd]-[SEQ_EG_CMP_ID]",
    "idname": "campaign.number"
}

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)

• https://github.com/egovernments/DIGIT-DevOps/blob/unified-env/deploy-as-code/helm/environments/unified-qa.yaml

• https://github.com/egovernments/DIGIT-DevOps/tree/unified-env/deploy-as-code/helm/charts/health-services/project-factory

• Heath-hrms, health-project, health-individual and facility should have specified heap and memory limits as mentioned below

heap: "-Xmx256m -Xms256m"
memory_limits: 512Mi

• 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

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.

Create Campaign

Endpoint

POST /project-type/create

Request Structure

Body Parameters

• 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

Response Structure

Success Response

• ResponseInfo: Object containing ResponseInfo.

• CampaignDetails: The created campaign details.

Flow

Client Initiates Request

The client initiates a createCampaign request to the Project Factory Service.

Validation of Request

If the action is 'create':

1. The Project Factory Service validates the request schema.

2. It also validates the uniqueness of the campaign name in the database.

3. If the campaign name exists, an error is thrown.

If the action is 'draft':

1. The Project Factory Service validates the request schema.

2. It also validates the uniqueness of the campaign name in the database.

3. If the campaign name exists, an error is thrown.

Boundary and MDMS Validation

For both 'create' and 'draft' actions:

1. The Project Factory Service validates the request for hierarchy type and boundaries with the Boundary Service.

Campaign Creation

If the action is 'create':

1. The Project Factory Service validates the request for data resources.

2. It enriches the CampaignDetails and sets the status to 'creating'.

3. The CampaignDetails are persisted in the database.

4. For each resource data, the Project Factory Service creates resources through the /project-factory/v1/data/_create API.

5. It enriches boundaries for project creation and creates projects for each boundary with the Health Project Service.

6. The enriched CampaignDetails are persisted in the database.

7. The CampaignDetails object is sent to a Kafka topic for project mappings.

8. 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'.

9. If the campaign status is already 'created', an error is thrown, and the status is updated to 'failed'.

If the action is 'draft':

1. The CampaignDetails are enriched, and the status is set to 'drafted;.

2. The enriched CampaignDetails are persisted in the database.

Response

The Project Factory Service sends the response back to the client.

Flow Diagram

Update Project Type Campaign

Endpoint

POST /project-type/update

Request Structure

Body Parameters

• 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.

Response Structure

Success Response

• ResponseInfo: Object containing ResponseInfo.

• CampaignDetails: The updated campaign details.

Flow

Receive Request

The ProjectFactoryService receives an updateCampaign request from the Client.

Validate Request Schema

The received request schema is validated to ensure it matches the expected format.

Check Campaign Existence

The system checks if the campaign specified in the request exists in the database.

Conditional template generation call

• 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

Check Campaign Status

If the campaign exists, the system checks its status in the database.

Handle Drafted Status

If the campaign status is 'drafted':

1. Validate Boundaries: Validate the request for hierarchyType and boundaries.

3. Enrich Campaign Details: Enrich the campaign details and set the status to 'updating'.

4. Update Campaign Details: Update the campaign details in the database.

5. Update Resource Data: Update each resource data associated with the campaign through the /project-factory/v1/data/_update API.

6. Enrich Boundaries: Enrich the boundaries for the project update.

7. Update Projects: Update projects associated with each boundary.

8. Persist Changes: Persist the updated campaign details in the database.

9. Send to Kafka Topic: Send the updated CampaignDetails object to the Kafka topic for project mappings.

10. Listen to Kafka: Listen for updates from the Kafka topic to get the updated CampaignDetails object for project mappings.

Handle Campaign Status

If the campaign status is not 'created':

1. Do project mapping through /project-factory/v1/project-type/createCampaign API.

2. Enrich the CampaignDetails and set the status to 'created'.

3. Update the CampaignDetail in the database.

Handle Project Mapping Error

If the campaign status is 'created':

1. Throw an error indicating that the project is already mapped for this campaign.

2. Enrich the CampaignDetails and set the status to 'failed'.

3. Update the CampaignDetail in the database.

Handle Non-Drafted Status

If the campaign status is not 'drafted', the system throws an error indicating that only drafted campaigns can be updated.

Send Response

The ProjectFactoryService sends a response to the Client based on the outcome of the update operation.

Flow Diagram

Search Project Type Campaign

Endpoint

POST /project-type/search

Request Structure

Body Parameters

• 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.

Response Structure

Success Response

• ResponseInfo: Object containing ResponseInfo details.

• CampaignDetails: Array containing details of matching campaigns.

• totalCount: Total number of matching campaigns.

Flow

Client Initiates Request

The client sends a searchCampaign request to the Project Factory Service.

Validation of Request

The Project Factory Service validates the request schema and search criteria.

Search Campaigns

• 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.

Response

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.

Flow Diagram

Search Process Tracks

Endpoint

POST /project-type/getProcessTrack

Request Structure

Query Parameters:

• campaignId: Unique ID of the campaign.

Response Structure

Success Response:

• ResponseInfo: Object containing ResponseInfo details.

• processTrack: Array containing process tracks of the matching campaign.

Flow

1. Client Initiates Request

   • The client sends a request to retrieve process tracks for a specific campaign by providing the campaignId.

2. Validation of Request

   • The Project Factory Service validates the provided campaignId to ensure it meets the expected format and constraints.

3. 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.

4. 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.

5. Send Response to Client

   • The Project Factory Service sends the response back to the client containing the process track details for the specified campaign.

Steps and Statuses in Campaign Creation

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.

processTrackStatuses

This 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.

Flow Diagram

Overview

The documentation details APIs for creating, searching, generating, and downloading data, including request/response structures, flows, and error handling.

Create Data

Endpoint

• Endpoint: /data/_create

• Method: POST

Request Structure

• 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).

Response Structure

• Success Response:

  - ResponseInfo: Object containing response information.

  - ResourceDetails: Array containing the detail objects of the created or validated resource.

Flow

1. Client Initiates Request: The client sends a createData request to the Project Factory service.

2. Validation of Request: The Project Factory service validates the request schema and the provided resource details.

3. 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.

4. Response: The Project Factory service sends the response back to the client containing the resource details and status.

Flow Diagram

Parsing Logic from sheet

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:

Parsing Logic Using parseArrayConfig.parseLogic

The parseArrayConfig.parseLogic configuration specifies how each column in the sheet should be processed. Here's how the parsing logic works:

Column Configuration

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.

Validating Column Names

During the validation step, the function checks that the first-row value matches the expected column name.

Processing Rows

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.

Example Conversion

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.

Search Data API

Endpoint

• Endpoint: /data/_search

• Method: POST

Request Structure

• 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.

Response Body Structure

• ResponseInfo: Object containing response information.

• ResourceDetails: Array containing the details object of the searched resource.

Flow

1. Client Request: The client sends a POST request to /data/_search.

2. Request Content: Includes RequestInfo and SearchCriteria.

3. Validation: The server validates request structure and content.

4. Response Creation: The server creates a response with info and resource details.

5. Response Dispatch: Sends response back to client.

6. Error Handling: If errors occur, generate an error response and send it.

Flow Diagram

Generate Data API

Endpoint

• Endpoint: /data/_generate

• Method: POST

Request Structure

• 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.

Response Structure

• ResponseInfo: Object containing response information.

• GeneratedResource: Array containing the details object of the generated resource.

Flow

1. Client Request: The client sends a POST request to /v1/data/_generate.

2. Request Validation: Aftern receiving the request, the server validates the request structure and parameters.

3. 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.

4. Response Creation: After processing the request, the server creates a response containing the details of the generated resource.

5. Response Dispatch: The server sends the generated response back to the client.

6. Error Handling: If errors occur, generate an error response and send it.

Flow Diagram

Data to Sheet Parsing Logic

1. Fetch Required Columns from MDMS:

   • Use callMdmsData to get type schema columns in the correct order.

2. Define Headers:

   • MDMS schema required columns are headers and ensures column orders.

3. Localise Headers:

   • Use getLocalizedHeaders with localizationMap.

4. Localise Sheet Name:

   • Use getLocalizedName with localizationMap and generate a sheet.

Adding a New Column to the Generated Sheet

To add a new column to the Generated sheet, follow these steps:

1. Search Schema Details

   • Locate the type schema from the HCM-ADMIN-CONSOLE.adminSchema schema in the workbench.

2. 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.

3. 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.

4. Ensure Column Uniqueness

   • Ensure that the isUnique property is correctly set for string columns to enforce uniqueness.

5. Column Visibility (Future Implementation)

   • Note that hideColumn and freezeColumn features will be implemented in the next version.

Sheet Data Validation:

This process is sufficient for validating the new column in the generated sheet.

Column Change Reflection in APIs

If there's a need to reflect the column in APIs, follow these additional steps:

1. 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.

Template Properties

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.

Download Data API

Endpoint

• Endpoint: /data/_download

• Method: POST

Request Structure

• 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.

Response Structure

• ResponseInfo: Object containing response information.

• ResourceDetails: Array containing the details object of the downloaded resource.

Flow

1. Client Request: The client sends a POST request to download data.

2. Request Validation: Upon receiving the request, the server validates the request structure and parameters.

3. 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.

4. 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.

5. Response Dispatch: The server sends the generated response back to the client.

6. Error Handling: If errors occur during the process, an error response is generated and sent.

Flow Diagram

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.

Master Data

The following are the various master data that will be used during the campaign creation process.

1. Different types of campaign and delivery rules.

2. Attributes on which delivery rules can be created.

3. Schema to validate the Excel data for different templates.

4. Parsing and transforming templates.

5. Type to API mapping.

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.

Dependencies

1. Project

2. Facility

3. Product

4. HRMS

5. MDMS

6. Boundary

7. Localisation

8. Access Control

9. IdGen

10. Individual

11. User

API Specification

Base Path: /project-factory/

API Contract Link

Data Model

DB Schema Diagram

Web Sequence Diagrams

Data Create API

Generate Data API

Process Create Campaign API

Process Track api

Below are the configurations needed for successfully setting up the campaign module:

MDMS Configuration

• citymodule needed to run campaign module in an environment:

  Link:

• roleactions config needed for the user for all campaign access

  Link:

• actionTest config needed for sidebar action and user access for services

  LINK:

  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:
• Hierarchy config needs to be added to define lowset hierarchy in boundary selection:

Devops Configuration

• Global configuratio needs to be added to environments.
• Helm chart needs to be added in devops.

Localisation

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 to get all the MDMSv2 schemas and data.

1. Data for schema HCM-ADMIN-CONSOLE.attributeConfig

1. Data for schema HCM-ADMIN-CONSOLE.deliveryTypeConfig

1. Data for schema HCM-ADMIN-CONSOLE.deliveryConfig

1. Data for schema HCM-ADMIN-CONSOLE.facilityschema

1. Data for schema HCM-ADMIN-CONSOLE.adminSchema

1. Data for schema HCM-ADMIN-CONSOLE.baseTimeout

1. Data for schema HCM-ADMIN-CONSOLE.mailConfig

1. Data for schema HCM-ADMIN-CONSOLE.operatorConfig

1. Data for schema HCM-ADMIN-CONSOLE.productType

1. Data for schema HCM-ADMIN-CONSOLE.readMeConfig

1. Data for schema HCM-ADMIN-CONSOLE.Boundary

1. Data for schema HCM-ADMIN-CONSOLE.hierarchyConfig

1. Data for schema HCM-ADMIN-CONSOLE.userSchema

Role-Action Mapping

data/pg/ACCESSCONTROL-ACTIONS-TEST/actions-test.json

data/pg/ACCESSCONTROL-ROLES/roles.json:

Boundary Bulk Upload for Campaign

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.

Sequence Diagram

Format of Excel for Boundary Bulk Upload

The Excel sheet should be formatted as follows:

Unique Code Generation

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.

getAutoGeneratedBoundaryCodes Function

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:

1. Initialise Column Data:

   • Initialise an array to store column data.

2. Extract Unique Elements:

   • Iterate through each row of the boundary list.

   • Extract unique elements from each column.

3. 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.

4. Default Code Generation:

   • Generate default code if parent code is not found.

5. Updated Element Codes Map

   Return Updated Boundary Data - Auto-Generated Code Map.

Boundary Entities Creation

Boundary entities are created chunk-wise, with each chunk consisting of 200 codes.

Create Boundary Entities

Purpose:

To create new boundary entities in the system from provided boundary codes.

Steps:

1. Convert Boundary Map:

   • Change the boundary map to a list of objects with key and value.

2. Prepare Request:

   • Set up the request details and initialise lists for boundaries and existing codes.

3. Chunk Boundary Codes:

   • Divide the boundary codes into smaller groups.

4. Fetch Existing Boundaries:

   • Check the system for existing boundary codes and collect them.

5. Identify New Boundaries:

   • Determine which boundary codes are new and add them to the list of boundaries to create.

6. Create New Boundaries:

   • If there are new boundaries, send them to the system in groups and log the results.

7. Handle Existing Boundaries:

   • Log a message if all boundaries already exist.

8. Error Handling:

   • Manage any errors that occur and provide a relevant error message.

Boundary Relationship Creation

Create Boundary Relationship

Purpose:

To create boundary relationships in the system from provided boundary codes and their parent-child mappings.

Steps:

1. Convert Boundary Map:

   • Transform the boundary map to a list of {key, value} objects.

2. Initialise Request:

   • Prepare the request details and activity messages array.

3. Fetch Existing Relationships:

   • Retrieve existing boundary relationships and extract their codes.

4. 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.

5. Handle Existing Relationships:

   • If all relationships already exist, log a validation error.

6. Attach Activity Messages:

   • Add activity messages to the request body.

7. Error Handling:

   • Catch, log, and handle errors appropriately.

Localisation Upsert of Codes

Boundary codes are localised to their corresponding names as specified in the uploaded Excel sheet.

Boundary Bulk Upload Upsertion

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 for Boundary Bulk Upload

API request for boundary bulk upload:

Note: Ensure the API endpoint, headers, and payload are customised as per your environment and requirements.

In the 'Delivery Details' step, users encounter 3 screens:

• Delivery Dates

• Cycle Configuration

• Delivery

1. Campaign Dates

This screen asks a user to fill in the start and end date of the campaign.

2. Cycle Configuration Screen

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:

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.

3. Delivery Screen

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 which 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:

Select or Create a Product

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.

Guide on Setting Up Delivery Configuration.

Here you can find the config of delivery based on project type.

The following is the structure of 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 in 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:

Reference links:

MDMS:

HOOKS:

New changes

We have added Delivery type at each delivery conditions showing the delivery type of the campaign.

It is configurable in mdms for the SMC project type. We can add default delivery type at each conditions.

deliveryConfig: It will contain default data of all deliveries.

conditionConfig: It will contain default data of each delivery condition of each deliveries

deliveryType: Default value of delivery type.

API Details

New Feature:

A info card is been added in both the screens in the delivery details. Which states the criteria of delivery as recommended by WHO.