Process API - Manual

Endpoint

  • Endpoint: /boundary-service/v1/_process

  • Method: POST

Request Structure

Query Parameters:

  • tenantId: Tenant identifier

  • referenceId: Reference identifier (optional)

Body Parameters:

  • RequestInfo: Object containing request information

  • ResourceDetails: Object containing the details of the boundary data to be processed

    • tenantId: Tenant identifier

    • hierarchyType: Type of hierarchy (e.g., ADMIN, MICROPLAN)

    • fileStoreId: File store ID of the uploaded Excel file

    • action: Action type (create)

    • referenceId: Reference identifier (optional)

Request Example

Flow

  1. Client Initiates Request: The client sends a process request to the Boundary Management service with Excel file containing user-provided boundary codes.

  2. Fetch Localization Maps: Service fetches localization maps for hierarchy-specific and boundary management modules.

  3. Validation of Request: The service validates the request and performs pre-processing validations: - Validates tenantId - Validates hierarchyType - Validates fileStoreId - Validates action is "create"

  4. Generate Unique ID: Generate a unique UUID for the process request.

  5. Set Audit Details: Enrich ResourceDetails with audit details: - Set createdBy and lastModifiedBy from RequestInfo userInfo - Set createdTime and lastModifiedTime to current timestamp

  6. Persist Initial Record: - Set status to 'accepted' - Persist the initial ResourceDetails record to database via Kafka (save topic)

  7. Return Immediate Response: Return to client with status 'accepted' and HTTP 200.

  8. Start Background Processing: - Download Excel file from FileStore - Get current flow from database (auto/manual) - Get hierarchy definition from Boundary Service - Validate Excel sheet headers and data - Segregate data (withBoundaryCode, withoutBoundaryCode, manualBoundaryCode) - Validate flow consistency

  9. Manual Boundary Code Processing (Manual Flow): - Validate all rows have boundary codes (no empty codes allowed) - Track boundaries at each hierarchy level - Validate all parent boundaries have codes - Build boundaryMap from user-provided codes - Add already processed boundary codes to map for parent-child relationships

  10. Validate Duplicate Codes: - Check for duplicate codes within submission - Prevents race conditions before database creation

  11. Check for Mixed Flow: - Ensure not mixing auto and manual flows - All rows must have codes (manual) or all empty (auto)

  12. Validate Flow Consistency: - Compare with existing flow from database - Throw error if flow mismatch (auto vs manual)

  13. Create Boundary Entities: - Check existing entities in chunks of 20 - Create new entities with user-provided codes in chunks of 200 - Wait 2 seconds for persistence

  14. Create Boundary Relationships: - Build child-parent map from manual boundary codes - Build modified child-parent map using codes - Confirm parent exists (retry up to 6 times) - Create boundary relationships - Throw error if boundary already exists

  15. Create Localization Messages: - Create French localization messages - Create Portuguese localization messages - Create default (English) localization messages

  16. Generate Processed Excel File: - User codes already present in data - Create Excel workbook with headers and data - Upload to FileStore

  17. Update Status: - Success Case:

    • Set status to 'completed'

    • Set processedFileStoreId with uploaded file ID

    • Clear any error details from additionalDetails

    • Update lastModifiedTime and lastModifiedBy

    • Persist to database via Kafka (update topic) - Failure Case:

      • Set status to 'failed'

    • Set processedFileStoreId to null

    • Enrich additionalDetails with error information (errorCode, errorMessage)

    • Update lastModifiedTime and lastModifiedBy

    • Persist to database via Kafka (update topic)

  18. Trigger Generate API: After 30 seconds, trigger /v1/_generate API with determinedCurrentFlow for downloadable file creation.

Flow Diagram

Status States

The process goes through the following status states:

  • accepted: Initial state when the process request is received and validated. Processing is queued for background execution.

  • started: Processing has begun (used for non-create actions).

  • completed: Boundary data successfully processed. Entities created, relationships established, and processed file uploaded. The processedFileStoreId field contains the file identifier.

  • failed: The processing encountered an error. Error details are available in additionalDetails:

    • error: Stringified JSON containing status, code, description, and message

  • invalid: Data validation failed but processing continues with some errors.

Last updated

Was this helpful?