Design Overview

1. New Schema: [extractor].[Job]

We will introduce a new SQL schema to track extractor job executions.

Table: [extractor].[Job]

Indexes

• IX_FileID
• IX_ClientApplicationExtractorID
• IX_Status

2. Lifecycle Flow

Trigger: File Accepted

• File arrives and is written to Blob Storage
• FileAccepted message is published to TOPIC_ACCEPTED_FILE

Step 1: Extractor Service Receives Message

• Lookup ClientApplicationID associated with file
• Call GET /registration/:clientAppId/extractors (new endpoint)
• Receive array of active extractors (filtered on IsActive = true)

Step 2: Start First Extractor (MVP scope)

• Pick the first extractor from the list
• Generate new JobID (UUID)
• Call extractor’s ExtractionUrl with:

{
  "fileUrl": "<signed blob url>",
  "jobId": "<JobID>"
}

• Insert new record into [extractor].[Job] with status Queued
• Publish JobQueued message to TOPIC_JOB_STATUS

3. Service Bus Messaging

Messages from Extractor

All status transitions publish messages to Service Bus, consumed by the Status service:

All use a consistent envelope structure already understood by the Status service.

4. Registration Endpoint

Route: GET /registration/:clientAppId/extractors

Returns:

[
  {
    "clientApplicationExtractorId": 101,
    "extractionUrl": "https://..."
  }
]

• Filters by IsActive = true
• Used by the Extractor service to determine which jobs to start

5. Security & Access

• Extractor service must have DB write access to [extractor] schema
• Extractor uses existing registration.apiClient.ts to call Registration service
• Service Bus message schema will be versioned and appended to platform docs