Technical Documentation: Update Campaign Web Flow

Overview

This document describes the web flow for updating an existing campaign using the Admin Console. The process involves interactions between the user and several backend services, ensuring the campaign data is updated correctly and validated before finalizing changes.

Actors and Participants

• User: The person interacting with the Admin Console to update an existing campaign.

• CampaignManager (Admin Console): The primary interface that the user uses to manage and update campaign information.

• ProjectFactory: Responsible for handling the creation and updating of campaign objects and validating the data.

• BoundaryService: Provides the boundary hierarchy definitions and relationship data necessary for the campaign.

• MDMSService: Supplies master data such as project types, hierarchy configurations, and other templates.

• FileStoreService: Manages the storage and retrieval of files related to the campaign.

Sequence Flow

1. Initiating Campaign Update

• User: Begins the update process by selecting an existing campaign from the "My Campaign" screen within the Admin Console.

• CampaignManager: Receives the request to update a specific campaign and retrieves the campaign object using its unique ID.

2. Fetching Campaign Data

• CampaignManager sends a request to ProjectFactory to fetch the campaign object based on the provided campaign ID.

  • ProjectFactory responds with the campaign object containing the current campaign details.

3. Fetching Boundary Information

• CampaignManager requests BoundaryService to fetch boundary hierarchy definitions based on the campaign's hierarchy type.

  • BoundaryService responds with the boundary hierarchy definition.

• CampaignManager requests BoundaryService to fetch boundary relationship data based on the hierarchy type.

  • BoundaryService responds with the boundary relationship data.

4. User Data Input

• User: Updates the necessary fields, such as boundary delivery configuration and other campaign-specific details, using the Admin Console.

• CampaignManager: Sends the updated information to ProjectFactory to create or update the campaign object, storing it with an action status of "draft".

5. Template Generation

• ProjectFactory: Automatically triggers the generation of templates for different resources, including:

  • Target templates

  • Facility templates

  • User templates

6. Template Download and Storage

• User: Downloads the generated templates for each resource type via the Admin Console.

• CampaignManager: Sends a request to FileStoreService to store the downloaded files.

  • FileStoreService responds with a filestoreid that uniquely identifies the stored file.

7. Data Validation

• CampaignManager: Sends the data and the filestoreid to ProjectFactory for validation.

  • ProjectFactory responds with a unique validation ID, as the validation process may take some time.

• CampaignManager: Periodically checks the validation status using the unique validation ID.

8. Validation Outcome

• ProjectFactory:

  • If validation is successful:

    • Responds with a success message.

    • CampaignManager: Displays a success message to the user, indicating that they can proceed to the next step.

  • If validation fails:

    • Responds with an error message detailing the validation failure.

    • CampaignManager: Displays the error message to the user, prompting them to correct the errors and re-upload the files.

9. Final Campaign Update

• User: Once all required data is filled in and validated, the user reviews the summary of the campaign data and clicks on the "Update Campaign" button.

• CampaignManager: Sends a request to ProjectFactory with the campaign update API, marking the action as "update".

10. Campaign Update Outcome

• ProjectFactory:

  • If the update is successful:

    • Responds with a success message, indicating that the campaign update has started.

    • CampaignManager: Displays a success message to the user, confirming that the campaign has been updated successfully.

  • If the update fails:

    • Responds with an error message detailing the failure.

    • CampaignManager: Displays the error message to the user, prompting them to correct any issues and try again.

Error Handling

• Validation Failures: If validation fails at any stage (e.g., during file validation or input data checks), the CampaignManager will notify the user of the specific issues. The user must resolve these issues and re-upload the necessary data to proceed.

• Service Errors: If any of the services (e.g., BoundaryService, ProjectFactory) encounter an error during processing, the CampaignManager will display an error message, detailing the problem and suggesting corrective actions.

Web Sequence Diagram

Conclusion

This document outlines the flow for updating an existing campaign using the Admin Console. The structured sequence ensures that any changes to the campaign are thoroughly validated and processed, minimizing errors and ensuring the integrity of the campaign data. By following this flow, users can confidently update campaigns, knowing that all necessary steps are taken to verify and finalize their changes.

Click here to know more.

Technical Documentation: Update Campaign Flow

Overview

This document outlines the flow for updating an existing campaign using various services in the system. The process involves interactions between multiple services, including the Project Factory, Project Service, Boundary Service, Facility Service, HRMS Service, MDMS Service, FileStore Service, and the database. The update flow ensures that the required resources are validated and updated correctly before finalizing the campaign update.

Actors and Participants

• Client: The entity (user or system) initiating the campaign update request.

• CampaignManager (Project Factory): The main controller managing the campaign update process.

• ProjectService: Manages project-related operations, including data creation and mapping updates.

• BoundaryService: Handles fetching of boundary relationships based on hierarchy types.

• FacilityService: Responsible for creating and updating facility-related data.

• HRMSService: Manages the creation and updating of employee data.

• MDMSService: Provides master data such as project types.

• FileStoreService: Manages the storage and retrieval of resource files.

• Database: Stores campaign-related data and status updates.

Sequence Flow

1. Initiate Campaign Update

   • The Client sends an update request to the CampaignManager with all required and valid resources.

2. Fetch Boundary Relationship

   • The CampaignManager requests the BoundaryService to fetch the boundary relationship based on the hierarchy type.

   • The BoundaryService responds with the relevant boundary relationship data.

3. Fetch Project Type Master

   • The CampaignManager requests the MDMSService to fetch the project type master data.

   • The MDMSService responds with the project type master.

4. Validate Resource Files

   • The CampaignManager queries the Database to check if the input resource files have already been validated.

   • The Database responds with the validation status of the files.

5. Fetch Parent Campaign Object

   • The CampaignManager queries the Database to fetch the parent campaign object based on the parentCampaignId.

   • The Database responds with the parent campaign object.

6. Validation Check

   • The CampaignManager checks if all file templates and data are validated:

     • If validation is successful, the CampaignManager informs the Client that the campaign update process has started, and the user needs to track the status using an ID.

     • If validation fails, the CampaignManager returns an error message, indicating which validation failed, and the user must resubmit the request.

7. Deactivate Parent Campaign

   • The CampaignManager updates the Database to mark the parent campaign object as inactive.

8. Retrieve Resource Files

   • The CampaignManager interacts with the FileStoreService to search for the resource based on the filestoreid.

   • The FileStoreService responds with the valid resource files.

9. Process Resource Data

   • The CampaignManager processes the retrieved sheets to identify any resource data that needs to be created.

10. Facility Data Creation

    • The CampaignManager sends a request to the FacilityService to create facility data.

    • The FacilityService responds that the facilities have been created successfully.

11. Employee Data Creation

    • The CampaignManager sends a request to the HRMSService to create employee data.

    • The HRMSService responds that the employees have been created successfully.

12. Search for Parent Project

    • The CampaignManager sends a request to the ProjectService to search for the previous or parent project.

    • The ProjectService responds with the project object.

13. Create New Projects for Added Boundaries

    • The CampaignManager copies the project content from the parent project while creating new projects for newly added boundaries.

    • The CampaignManager sends a request to the ProjectService to create project data for newly added boundary data and map it according to its parent.

    • The ProjectService responds that the projects have been created successfully.

14. Update Facility Data

    • The CampaignManager identifies what exact data needs to be updated for facilities.

    • The CampaignManager sends a request to the ProjectService to create project-facility mapping if any new facilities are added.

    • The ProjectService responds that the project-facility mapping has been created successfully.

    • The CampaignManager sends a request to the ProjectService to search for the previous project-facility mapping.

    • The ProjectService responds with the project-facility mapping data.

    • The CampaignManager sends a request to the ProjectService to update the project-facility mapping.

    • The ProjectService responds that the project-facility mapping has been updated successfully.

15. Update Staff Data

    • The CampaignManager identifies what exact data needs to be updated for staff.

    • The CampaignManager sends a request to the ProjectService to create project-staff mapping if any new staff are added.

    • The ProjectService responds that the project-staff mapping has been created successfully.

    • The CampaignManager sends a request to the ProjectService to search for the previous project-staff mapping.

    • The ProjectService responds with the project-staff mapping data.

    • The CampaignManager sends a request to the ProjectService to update the project-staff mapping.

    • The ProjectService responds that the project-staff mapping has been updated successfully.

16. Update Campaign Status

    • The CampaignManager updates the Database with the campaign update status.

Error Handling

• Validation Failure: If any validation step fails (e.g., invalid data in resource files or missing required resources), the CampaignManager sends an error message to the Client, indicating the failure. The user is required to fix the issues and resubmit the request.

• Service Errors: If any of the service interactions (e.g., BoundaryService, MDMSService, ProjectService) return an error, the CampaignManager stops the process and informs the Client of the failure, specifying the nature of the error.

• Database Errors: If the Database fails to update the campaign update status or mark the parent campaign as inactive, appropriate error handling and logging mechanisms should be triggered to handle the failure.

API Sequence Diagram

Conclusion

This document provides a comprehensive overview of the update campaign flow, detailing each step and interaction between different services and the database. The flow ensures proper validation and updating of necessary resources, while error handling mechanisms provide robustness to the process.

Technical Documentation: Create Campaign Flow

Overview

This document outlines the flow for creating a campaign using various services in the system. The process involves interactions between multiple services, including the Project Factory, Project Service, Boundary Service, Facility Service, HRMS Service, MDMS Service, FileStore Service, and the database. This flow ensures that the required resources are validated and correctly set up before finalizing the campaign creation.

Actors and Participants

• Client: The entity (user or system) initiating the campaign creation request.

• CampaignManager (Project Factory): The main controller managing the campaign creation process.

• ProjectService: Manages project-related operations, including data creation and mapping.

• BoundaryService: Handles fetching of boundary relationships based on hierarchy types.

• FacilityService: Responsible for creating facility-related data.

• HRMSService: Manages the creation of employee data.

• MDMSService: Provides master data such as project types.

• FileStoreService: Manages the storage and retrieval of resource files.

• Database: Stores campaign-related data and status updates.

Sequence Flow

1. Initiate Campaign Creation

   • The Client sends a request to the CampaignManager to create a campaign with all required and valid resources.

2. Fetch Boundary Relationship

   • The CampaignManager requests the BoundaryService to fetch the boundary relationship based on the hierarchy type.

   • The BoundaryService responds with the relevant boundary relationship data.

3. Fetch Project Type Master

   • The CampaignManager requests the MDMSService to fetch the project type master data.

   • The MDMSService responds with the project type master.

4. Validate Resource Files

   • The CampaignManager checks the Database to see if the input resource files have already been validated.

   • The Database responds with the validation status of the files.

5. Validation Check

   • The CampaignManager checks if all file templates and data are validated:

     • If validation is successful, the CampaignManager informs the Client that the campaign creation process has started, and the user needs to track the status using an ID.

     • If validation fails, the CampaignManager returns an error message, indicating which validation failed, and the user must resubmit the request.

6. Resource File Retrieval

   • The CampaignManager interacts with the FileStoreService to search for the resource based on the filestoreid.

   • The FileStoreService responds with the valid resource files.

7. Process Resource Data

   • The CampaignManager processes the retrieved sheets and identifies any resource data that needs to be created.

8. Facility Data Creation

   • The CampaignManager sends a request to the FacilityService to create facility data.

   • The FacilityService responds that the facilities have been created successfully.

9. Employee Data Creation

   • The CampaignManager sends a request to the HRMSService to create employee data.

   • The HRMSService responds that the employees have been created successfully.

10. Project Data Creation

    • The CampaignManager sends a request to the ProjectService to create project data with a parent-child relationship based on the project type and delivery configuration.

    • The ProjectService responds that the projects have been created successfully.

11. Project-Facility Mapping Creation

    • The CampaignManager sends a request to the ProjectService to create mappings between projects and facilities.

    • The ProjectService responds that the project-facility mappings have been created successfully.

12. Project-Staff Mapping Creation

    • The CampaignManager sends a request to the ProjectService to create mappings between projects and staff.

    • The ProjectService responds that the project-staff mappings have been created successfully.

13. Update Campaign Creation Status

    • The CampaignManager updates the Database with the status of the campaign creation process.

Error Handling

• Validation Failure: If any validation step fails (e.g., invalid data in resource files), the CampaignManager sends an error message to the Client, indicating the failure. The user is required to fix the issues and resubmit the request.

• Service Errors: If any of the service interactions (e.g., BoundaryService, MDMSService) return an error, the CampaignManager stops the process and informs the Client of the failure, specifying the nature of the error.

• Database Errors: If the Database fails to update the campaign creation status, appropriate error handling and logging mechanisms should be triggered to handle the failure.

API Sequence Diagram

Conclusion

This document provides an overview of the create campaign flow, detailing each step and interaction between different services and the database. The flow ensures proper validation and creation of necessary resources, while error handling mechanisms provide robustness to the process.

Technical Design Document: Manage Resources API Flows

Overview

This document outlines the various API flows and interactions for the Project Factory, focusing on resource data creation with retry logic, template generation, campaign update flows, and data search and download processes. The aim is to manage and automate various aspects of resource and campaign data efficiently using the Project Factory services.

Project Factory Resources Data Create with Retry Logic

Description: This flow describes how the Project Factory handles resource data creation with retry logic. It ensures data consistency and reliability by retrying operations if failures occur.

Sequence of Operations:

1. Client Request Initiation:

   • The client sends a request to the Project Factory with filestoreid and type.

2. MDMS Service Interaction:

   • Project Factory retrieves the type schema from the MDMS Service.

   • MDMS Service returns the schema, which is then validated.

3. Data Validation:

   • The Project Factory validates the data against the MDMS schema.

   • If validation is successful, it informs the client that data processing has started.

   • If validation fails, an error message is returned, and the user must resubmit.

4. File Handling:

   • The Project Factory requests a file download from the FileStore Service.

   • Upon receiving the file, JSON data is created from the file of the desired type.

5. Data Creation and Retry Logic:

   • Data is validated according to the schema.

   • Normal Create:

     • Data is created in the respective service, and status is tracked.

     • A loop continues until retry attempts exceed the maximum retries, or no failed data remains.

   • Bulk Create with Retry:

     • Data is created in the respective service, and the status is checked.

     • A search is conducted using the generateApi search.

     • The loop continues under the same conditions as the normal create process.

6. Database Update:

   • The file is enriched with the created ID and sent back to the FileStore Service.

   • The updated file is received, and data is persisted in the database with a status of 'created' and the processed filestoreid.

Template Generate API Flow (forceUpdate = true)

Description: This flow is triggered when a client sends a generate request with forceUpdate = true. It checks for existing data and creates a new row with the status inProgress if necessary.

Sequence of Operations:

1. Client Request Initiation:

   • The client sends a generate request with the specified type and forceUpdate = true.

2. Validation and Data Check:

   • The Project Factory validates the type against predefined types and hierarchytype.

   • A check is performed to see if previous data exists. If it does, the data is marked as expired.

3. Database and Response:

   • A new row is created with null fileStoreId and status inProgress.

   • The database is updated, and a success response is sent back to the client.

4. Data Fetch and Storage:

   • The Project Factory fetches the template from the MDMS Service based on the type.

   • Data is consolidated and stored in the FileStore Service, which returns a filestoreid.

   • The database is updated with the new filestoreid.

Template Generate API During Update Campaign Flow (forceUpdate = true)

Description: This flow is initiated when a generate request is sent due to a boundary change in an ongoing campaign.

Sequence of Operations:

1. Boundary Change Trigger:

   • The Project Factory sends a generate request with campaignId, type, and forceUpdate = true.

2. Validation and Data Check:

   • The type is validated against predefined types and hierarchytype.

   • Previous data is checked, and if found, marked as expired.

   • The campaign is searched in the database based on the provided campaignId and its parent campaign ID.

3. Database and Response:

   • A new row is created with null fileStoreId and status inProgress.

   • The database is updated, and a response is provided.

4. File Update and Data Consolidation:

   • The Project Factory fetches file details from the FileStore Service using the parent campaign object.

   • The sheet is updated, freezing all the data.

   • If new boundaries are added, boundary relation data is fetched.

   • Data is consolidated, and stored in the FileStore, and the database is updated with the new filestoreid.

Project Factory Resources Data Search and Download

Description: This flow allows the client to search and download resource data based on a provided ID and type.

Sequence of Operations:

1. Client Request Initiation:

   • The client sends a request with the id and type.

2. Database Query:

   • The Project Factory checks the created resource based on the provided ID.

   • The corresponding resource details row is fetched from the database.

3. Response to Client:

   • The Project Factory sends back the created resource response to the client.

API Sequence Diagrams

During Create flow

During Update Flow

Conclusion

The outlined API flows are crucial for handling resource data creation, management, and retrieval efficiently. They ensure data consistency, integrity, and seamless interaction between various services, making the Project Factory a robust system for managing campaign data. Implementing the retry logic, data validation, and template generation processes helps maintain a reliable and scalable architecture.

Technical Documentation: Create Campaign Web Flow

Overview

This document details the web flow for creating a new campaign using the Admin Console. The process involves interactions between various services, including the Project Factory, Boundary Service, MDMS Service, FileStore Service, and the Admin Console. This flow ensures that all necessary data is collected, validated, and processed to create a campaign successfully.

Actors and Participants

• User: The person interacting with the Admin Console to set up and create a campaign.

• CampaignManager (Admin Console): The main interface that the user interacts with to manage campaign creation.

• ProjectFactory: Handles the creation and management of campaign objects and validation processes.

• BoundaryService: Provides information about boundary hierarchy and relationships.

• MDMSService: Supplies master data such as project types, hierarchy configurations, and operator details.

• FileStoreService: Manages the storage and retrieval of files related to the campaign.

Sequence Flow

1. Campaign Setup Initialization

• User: Initiates the process by visiting the Admin Console to set up a new campaign.

• CampaignManager: Receives the request to set up a campaign and starts interacting with various services to gather necessary information.

2. Fetch Master Data

• CampaignManager sends a request to MDMSService to fetch required master data, including:

  • Project types

  • Hierarchy type configuration

  • Operator templates

  • Other necessary templates

• MDMSService responds with the requested master data, which is used to configure the campaign.

3. Fetch Boundary Information

• CampaignManager requests BoundaryService to fetch boundary hierarchy definitions based on the selected hierarchy type.

  • BoundaryService responds with the boundary hierarchy definition.

• CampaignManager requests BoundaryService to fetch boundary relationship data based on the selected hierarchy type.

  • BoundaryService responds with the boundary relationship data.

4. User Data Input

• User: Fills in the required data such as boundary delivery configuration and other campaign-specific details within the Admin Console.

• CampaignManager: Sends the user-filled information to ProjectFactory to create a campaign object and stores it with an initial action status of "draft".

5. Template Generation

• ProjectFactory: Automatically triggers the generation of templates for different resources, including:

  • Target templates

  • Facility templates

  • User templates

6. Template Download and Storage

• User: Downloads the generated templates for each resource type through the Admin Console.

• CampaignManager: Sends a request to FileStoreService to store the downloaded files.

  • FileStoreService responds with a filestoreid that uniquely identifies the stored file.

7. Data Validation

• CampaignManager: Sends the data and the filestoreid to ProjectFactory for validation.

  • ProjectFactory responds with a unique validation ID as the validation process may take some time.

• CampaignManager: Periodically checks the status of the validation using the unique validation ID.

8. Validation Outcome

• ProjectFactory:

  • If validation is successful:

    • Responds with a success message.

    • CampaignManager: Displays a success message to the user, indicating that they can proceed to the next step.

  • If validation fails:

    • Responds with an error message detailing the validation failure.

    • CampaignManager: Displays the error message to the user, prompting them to correct the errors and re-upload the files.

9. Final Campaign Creation

• User: Once all required data is filled in and validated, the user reviews the summary of the campaign data and clicks on the "Create Campaign" button.

• CampaignManager: Sends a final request to ProjectFactory with the campaign creation API, marking the action as "create".

10. Campaign Creation Outcome

• ProjectFactory:

  • If the creation is successful:

    • Responds with a success message indicating that the campaign creation has started.

    • CampaignManager: Displays a success message to the user, confirming the campaign creation.

  • If the creation fails:

    • Responds with an error message detailing the failure.

    • CampaignManager: Displays the error message to the user, prompting them to correct any issues and try again.

Error Handling

• Validation Failures: If validation fails at any stage (e.g., during file validation or input data checks), the CampaignManager will notify the user of the specific issues. The user must resolve these issues and re-upload the necessary data to proceed.

• Service Errors: If any of the services (e.g., BoundaryService, MDMSService, ProjectFactory) encounter an error during processing, the CampaignManager will display an error message, detailing the problem and suggesting corrective actions.

Web Sequence Diagram

Conclusion

This document outlines the end-to-end flow for creating a new campaign using the Admin Console. It ensures that the user provides all required information, and that data is validated and processed correctly to create the campaign. This structured approach minimizes errors and ensures that all campaigns are set up with the required accuracy and completeness.

Technical Documentation: Checklist Management Web Flow

Overview

This document outlines the web flow for managing checklists within a campaign context, including viewing existing and creating new checklists. The process involves interaction between the user and various backend services to ensure the correct retrieval, creation, and modification of checklists associated with specific campaigns.

Actors and Participants

• User: The individual interacting with the checklist management UI to view, create, and modify checklists.

• Checklist View UI (CurrentScreen): This is the user interface for viewing existing checklists and initiating the creation of new ones.

• Checklist Create UI (CurrentScreen): The user interface for creating and configuring checklists.

• Service Request Service (ServiceRequestService): Manages service requests and updates related to checklists.

• MDMS Service (MDMSAPI): Provides master data management services for roles, checklist types, and other configurations.

• Localisation Service (LOCAPI): Manages the localization of checklist questions.

Sequence Flow

Checklist Viewing Flow

1. Access Checklist View UI

   • The user accesses the Checklist View UI after a campaign has been created.

2. Fetching Configured Service Requests

   • CurrentScreen sends a request to ServiceRequestService to fetch configured service requests.

     • ServiceRequestService filters and returns checklists using the campaign name, role, and type, or just the campaign name (if the service is enhanced).

   • ServiceRequestService returns the relevant checklists to CurrentScreen.

3. Display Checklists

   • CurrentScreen displays the checklists received from ServiceRequestService to the User.

4. Creating a New Checklist

   • The user clicks on "Create Checklist" in the Checklist View UI.

   • CurrentScreen sends a request to MDMSAPI to fetch role and checklist type master data relevant to the campaign type.

   • MDMSAPI returns the master data to CurrentScreen.

   • The user selects the desired role and checklist type.

   • CurrentScreen redirects to the checklist creation screen based on the selected campaign name, role, and type.

5. Enable/Disable Checklist

   • The user clicks on the enable/disable option for any checklist.

   • CurrentScreen sends an update call to ServiceRequestService to toggle the active/inactive status of the checklist.

   • ServiceRequestService returns the updated response.

   • CurrentScreen updates the checklist status based on the response.

Checklist Creation Flow

1. Access Checklist Create UI

   • The user accesses the Checklist Create UI.

   • CurrentScreen parses URL query parameters to determine the campaign name, role, and checklist type.

2. Fetching Draft Service Requests

   • CurrentScreen sends a request to MDMSAPI to fetch draft service requests based on the role and type.

   • MDMSAPI returns the configured draft service requests.

3. Loading Default Checklist Questions

   • CurrentScreen checks if there is a template available for the checklist and loads default checklist questions.

4. User Interaction for Checklist Questions

   • Users can add, delete, or modify any checklist questions in the UI.

   • The user clicks on "Create" to finalise the checklist.

5. Generating Unique Codes and Creating Service Requests

   • CurrentScreen generates a unique code for every checklist question.

   • CurrentScreen sends a create service request with the list of all questions to ServiceRequestService.

   • ServiceRequestService returns a successful response indicating that the checklist has been created.

6. Localisation of Checklist Questions

   • CurrentScreen sends a request to LOCAPI to create localisation for all checklist questions.

     • Each question is assigned a generated code, a user-entered message, and is associated with the hcm-checklist module.

   • LOCAPI processes the localisation request and returns a response.

7. Completion and Feedback

   • CurrentScreen displays a toast notification to the User indicating the successful creation of the checklist.

   • User is redirected back to the Checklist View screen, where they can see the newly created checklist.

Error Handling

• Service Request Failures: If a service request fails at any point, the CurrentScreen will display an error message to the User. Users must resolve the issues and retry the operation.

• Validation Errors: During checklist creation, if validation errors are detected, the CurrentScreen will notify the User with specific details, and the user must correct the issues before proceeding.

Web Sequence Diagram

Conclusion

This documentation provides a comprehensive overview of the checklist management process within a campaign. The structured sequence ensures that all checklist-related activities are handled correctly, from viewing existing checklists to creating and localizing new ones. By adhering to this flow, users can manage checklists efficiently, ensuring consistency and accuracy in their campaign management activities.

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

Table Details

```dbml
Table eg_cm_campaign_details {
  id varchar(128) [primary key ,not null, unique]
  tenantid varchar(64) [not null ,note: 'Tenant identifier']
  campaignname varchar(250) [not null ,note: 'Name of the campaign']
  projecttype varchar(128) [not null ,note: 'Type of project']
  startdate bigint [note: 'Start date in epoch']
  enddate bigint [note: 'End date in epoch']
  campaigndetails jsonb [note: 'Campaign specific details']
  status varchar(128) [not null ,note: 'Status of the campaign']
  parentid varchar(128) [note: 'refering to the previous campaign id']
  action varchar(64) [not null ,note: 'Action type']
  campaignnumber varchar(128) [not null ,note: 'Campaign number']
  hierarchytype varchar(128) [not null ,note: 'Hierarchy type']
  boundarycode varchar(64) [note: 'Boundary code']
  projectid varchar(128) [note: 'Project identifier']
  createdby varchar(128) [not null ,note: 'Created by user ID']
  lastmodifiedby varchar(128) [note: 'Last modified by user ID']
  createdtime bigint [note: 'Creation timestamp']
  lastmodifiedtime bigint [note: 'Last modification timestamp']
  additionaldetails jsonb [note: 'Additional details']
}
```

```dbml
Table eg_cm_campaign_process {
  id varchar(128) [primary key, not null, unique]
  campaignid varchar(128) [not null,note: 'Foreign key to eg_cm_campaign_details.id']
  type varchar(128) [not null,note: 'Type of campaign process']
  status varchar(128) [not null,note: 'Status of the campaign process']
  details jsonb [note: 'Detailed information of the process']
  createdtime bigint [note: 'Creation timestamp']
  lastmodifiedtime bigint [note: 'Last modification timestamp']
  additionaldetails jsonb [note: 'Additional details']
}
Ref: eg_cm_campaign_process.campaignid > eg_cm_campaign_details.id // many-to-one

```

```dbml
Table eg_cm_generated_resource_details {
  id varchar(128) [primary key,not null, unique]
  filestoreid varchar(128) [note: 'File store ID']
  status varchar(128) [not null,note: 'Status of the resource']
  type varchar(128) [not null,note: 'Type of resource']
  tenantid varchar(128) [not null,note: 'Tenant identifier']
  count bigint [note: 'Count of resources']
  createdby varchar(128) [note: 'Created by user ID']
  createdtime bigint [note: 'Creation timestamp']
  lastmodifiedby varchar(128) [note: 'Last modified by user ID']
  lastmodifiedtime bigint [note: 'Last modification timestamp']
  additionaldetails jsonb [note: 'Additional details']
  hierarchytype varchar(128) [not null,note: 'Hierarchy type']
  campaignid varchar(128) [note: 'Foreign key to eg_cm_campaign_details.id']
}
Ref: eg_cm_generated_resource_details.campaignid > eg_cm_campaign_details.id // many-to-one

```

```dbml
Table eg_cm_resource_activity {
  id varchar(128) [primary key,not null, unique]
  retrycount int [note: 'Number of retry attempts']
  type varchar(64) [not null,note: 'Type of activity']
  url varchar(128) [not null,note: 'URL for the activity']
  requestpayload jsonb [note: 'Request payload']
  tenantid varchar(128) [not null,note: 'Tenant identifier']
  responsepayload jsonb [note: 'Response payload']
  status bigint [note: 'Status code']
  createdby varchar(128) [note: 'Created by user ID']
  createdtime bigint [note: 'Creation timestamp']
  lastmodifiedby varchar(128) [note: 'Last modified by user ID']
  lastmodifiedtime bigint [note: 'Last modification timestamp']
  additionaldetails jsonb [note: 'Additional details']
  resourcedetailsid varchar(128) [not null,note: 'Foreign key to eg_cm_resource_details.id']
}
Ref: eg_cm_resource_activity.resourcedetailsid > eg_cm_resource_details.id // many-to-one

```

```dbml


Table eg_cm_resource_details {
  id varchar(128) [primary key,not null, unique]
  status varchar(128) [note: 'Status of the resource']
  tenantid varchar(128) [not null,note: 'Tenant identifier']
  filestoreid varchar(128) [note: 'File store ID']
  processedfilestoreid varchar(128) [note: 'Processed file store ID']
  action varchar(128) [not null,note: 'Action type']
  type varchar(64) [not null,note: 'Type of resource']
  createdby varchar(128) [note: 'Created by user ID']
  createdtime bigint [note: 'Creation timestamp']
  lastmodifiedby varchar(128) [note: 'Last modified by user ID']
  lastmodifiedtime bigint [note: 'Last modification timestamp']
  additionaldetails jsonb [note: 'Additional details']
  campaignid varchar(128) [note: 'Foreign key to eg_cm_campaign_details.id']
}

Ref: eg_cm_resource_details.campaignid > eg_cm_campaign_details.id // many-to-one


```

Web Sequence Diagrams

Data Create API

Generate Data API

Process Create Campaign API

Process Track api