search

Integration with Microplan

/project-factory/v1/project-type/fetch-from-microplan

hashtag
Overview

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.

hashtag
Services Used

  • Core Services

  • Plan Service

  • Census Service

hashtag
Sequence Flow

  1. Initiate Request: The request body for the microplan integration will be:

    {
    "RequestInfo": {
        "apiId": "Rainmaker",
        "authToken": "{{auth}}",
        "msgId": "1730962198879|en_MZ",
        "plainAccessRequest": {}
    },
    "MicroplanDetails": {
        "tenantId": "mz",
        "campaignId": "58fb49a9-6772-4ecf-afc1-61f747e8c412",
        "planConfigurationId": "e314a0b1-648c-4f7b-8551-f9441df00eb4"
    }
}

Here campaignId will be the id of campaign for which the current plan is linked
and planConfigurationId is the id of the microplan.

  2. Validations: This request validates whether the campaignId and planConfigurationId exist in the system or are invalid.

  3. Update Facility Sheet: 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.

    Copy

    {
            "id": "01a6cdc9-f777-4792-ad17-6dc7042fe1fd",
            "tenantId": "mz",
            "planConfigurationId": "f44bffa1-653a-455a-998d-e556ac097d3b",
            "planConfigurationName": "Malaria-SMC Campaign-M1x3d-1-26 Nov 24",
            "facilityId": "F-2024-11-26-104823",
            "facilityName": "angelic being 3713",
            "residingBoundary": "MICROPLAN_MO_13_05_02_02_07_ZAYBAY_TOWN",
            "serviceBoundaries": [
                "MICROPLAN_MO_13_05_01_03_04_GORBO_COMMUNITY",
                "MICROPLAN_MO_13_05_01_03_03_FDA_COMMUNITY",
                "MICROPLAN_MO_13_05_01_03_01_BARLAVILLE",
                "MICROPLAN_MO_13_05_01_02_12_GARLOVILLE_COMMUNITY",
                "MICROPLAN_MO_13_05_01_02_11_SUAH_COMMUNITY",
                "MICROPLAN_MO_13_05_01_02_10_KANNAH_ROAD_COMMUNITY",
                "MICROPLAN_MO_13_05_01_02_09_ZWEDRU_CENTRAL_MARKET",
                "MICROPLAN_MO_13_05_01_02_08_ZOE_BUSH",
                "MICROPLAN_MO_13_05_01_02_07_CITY_HALL_COMMUNITY",
                "MICROPLAN_MO_13_05_01_02_06_WELBO_QUARTER",
                "MICROPLAN_MO_13_05_01_02_05_TRIANGLE_COMMUNITY",
                "MICROPLAN_MO_13_05_01_02_04_SPS_COMMUNITY",
                "MICROPLAN_MO_13_05_01_02_03_BAPTIST_COMMUNITY",
                "MICROPLAN_MO_13_05_01_02_02_TOWAH_COMMUNITY",
                "MICROPLAN_MO_13_05_01_02_01_A_G__COMMUNITY",
                "MICROPLAN_MO_13_05_01_01_09_NAO_COMMUNITY",
                "MICROPLAN_MO_13_05_01_01_07_GBAGBAVILLE",
                "MICROPLAN_MO_13_05_01_01_06_ELRZ_COMMUNITY",
                "MICROPLAN_MO_13_05_01_01_05_MANDINGO_QUARTER",
                "MICROPLAN_MO_13_05_01_01_04_ZANBO_QUARTER",
                "MICROPLAN_MO_13_05_01_01_03_KYNE_QUARTER",
                "MICROPLAN_MO_13_05_01_01_02_GBOE_QUARTER",
                "MICROPLAN_MO_13_05_01_01_01_BOWEN_QUARTER"
            ],
            "additionalDetails": {
                "capacity": 1280,
                "fixedPost": "No",
                "facilityName": "angelic being 3713",
                "facilityType": "Storing Resource",
                "facilityStatus": "Temporary",
                "assignedVillages": [],
                "servingPopulation": 15272
            },
            "active": true,
            "auditDetails": {
                "createdBy": "29f73f64-2f5b-4699-b92c-4b093ac65749",
                "lastModifiedBy": "bae97a73-8c70-4e09-92fd-d1ae97321cb5",
                "createdTime": 1732615033646,
                "lastModifiedTime": 1732619625034
            }
        }

  4. Update Target Sheet: 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 the census search API, where the data looks like this:

     {
        "id": "baece49c-a7fa-49e7-bddd-d19ba71b2b89",
        "tenantId": "mz",
        "code": "HCM-ADMIN-CONSOLE.microplanIntegration",
        "description": "HCM-ADMIN-CONSOLE.microplanIntegration",
        "definition": {
            "type": "object",
            "title": "HCM-ADMIN-CONSOLE.microplanIntegration",
            "$schema": "http://json-schema.org/draft-07/schema#",
            "required": [
                "type",
                "mappings"
            ],
            "x-unique": [
                "type"
            ],
            "properties": {
                "type": {
                    "type": "string"
                },
                "mappings": {
                    "type": "array",
                    "minItems": 1,
                    "items": {
                        "type": "object",
                        "properties": {
                            "to": {
                                "type": "string"
                            },
                            "from": {
                                "type": "array",
                                "items": {
                                    "type": "string"
                                }
                            },
                            "filter": {
                                "type": "string",
                                "enum": [
                                    "includes",
                                    "equal"
                                ],
                                "default": "includes"
                            }
                        }
                    }
                }
            },
            "isActive": true,
            "auditDetails": {
                "createdBy": null,
                "lastModifiedBy": null,
                "createdTime": 1697098069220,
                "lastModifiedTime": 1697098069220
            }
        }
    }
```

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 the census search as follows:

  1. Update User Sheet: 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 utilised. 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:

hashtag
Conclusion

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.

  1. Facility Sheet: Generated using facility details from the planConfigurationId, enriched with service boundaries, validated, and updated in the campaign object.

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

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

PreviousSearch Project Type Campaign EndpointsNextUpdate Ongoing Campaign

Last updated

Was this helpful?