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