Mark Pinkster 9939300245 Block syncing and copying added

2026-01-16 12:16:43 +01:00

8.7 KiB

Raw Blame History

Plan: Transmission Synchronisatie met Talpa Updates

Probleem Beschrijving

Wanneer infomercials in de planning worden verplaatst, moeten de transmissions in Talpa ook worden bijgewerkt. Dit geldt voor:

De verplaatste infomercial zelf
Alle andere infomercials in hetzelfde uitzendblok (omdat hun starttijden verschuiven)

Momenteel wordt alleen bij de eerste synchronisatie een transmission aangemaakt in Talpa, maar er is geen mechanisme om bestaande transmissions te updaten wanneer de planning wijzigt.

Huidige Situatie

Database Schema

De transmissions tabel heeft:

id - lokale database ID
api_status - status: 'pending', 'synced', 'error'
api_response - JSON response van Talpa API
GEEN dedicated kolom voor Talpa transmission ID

Huidige Flow

Aanmaken: create_transmission.php maakt lokale transmission aan met status 'pending'
Sync: sync_block.php synchroniseert naar Talpa en zet status op 'synced'
Update: update_transmission.php update lokale data en zet status terug naar 'pending'
Probleem: Er is geen mechanisme om Talpa te updaten na wijzigingen

Talpa API

POST /linearSchedule/v1/transmissions - Aanmaken (retourneert id in response)
PUT /linearSchedule/v1/transmissions/{id} - Update (nog niet geïmplementeerd)

Oplossing Architectuur

1. Database Wijzigingen

Voeg nieuwe kolom toe aan transmissions tabel:

ALTER TABLE transmissions 
ADD COLUMN talpa_transmission_id VARCHAR(100) NULL 
COMMENT 'Talpa API transmission ID voor updates';

Rationale:

Dedicated kolom is beter dan JSON parsing uit api_response
Makkelijker te indexeren en queryen
Duidelijker in code

2. TalpaAPI Uitbreiding

Voeg nieuwe methode toe aan TalpaAPI.php:

public function updateTransmission($transmissionId, $data) {
    return $this->request('PUT', '/linearSchedule/v1/transmissions/' . $transmissionId, [
        "startDate" => $data['startDate'],
        "startTime" => $data['startTime'],
        "duration" => $data['duration']
    ]);
}

3. Sync Block Wijzigingen

Update sync_block.php:

Bij succesvolle sync: extract id uit response en sla op in talpa_transmission_id
Ondersteun zowel nieuwe transmissions (POST) als bestaande (PUT)

Logica:

IF talpa_transmission_id IS NULL:
    → POST nieuwe transmission
    → Sla transmission_id op
ELSE:
    → PUT update bestaande transmission

4. Update Transmission Wijzigingen

Update update_transmission.php:

Na lokale update: check of talpa_transmission_id bestaat
Zo ja: direct Talpa updaten (niet wachten op sync)
Update ook andere transmissions in hetzelfde blok

Cascade Update Logica:

1. Bepaal welk blok de transmission behoort
2. Haal alle transmissions in dat blok op (gesorteerd op tijd)
3. Herbereken starttijden vanaf de gewijzigde transmission
4. Update alle affected transmissions:
   - Lokaal: nieuwe start_time
   - Talpa: PUT update (als talpa_transmission_id bestaat)

5. Insert at Position Wijzigingen

Update insert_transmission_at_position.php:

Na insert: herbereken alle volgende transmissions in blok
Update Talpa voor alle transmissions met talpa_transmission_id

Implementatie Details

Scenario 1: Nieuwe Transmission

graph LR
    A[Create Transmission] --> B[Status: pending]
    B --> C[Sync Block]
    C --> D[POST to Talpa]
    D --> E[Save talpa_transmission_id]
    E --> F[Status: synced]

Scenario 2: Update Bestaande Transmission

graph LR
    A[Update Transmission] --> B[Check talpa_transmission_id]
    B -->|Exists| C[PUT to Talpa]
    B -->|NULL| D[Status: pending]
    C --> E[Update Cascade]
    E --> F[Update Other Transmissions in Block]
    F --> G[PUT each to Talpa]

Scenario 3: Insert at Position

graph LR
    A[Insert at Position] --> B[Create New Transmission]
    B --> C[Recalculate Block Times]
    C --> D[Update All Following Transmissions]
    D --> E[POST new to Talpa]
    E --> F[PUT updates to Talpa]

Benodigde Functies

Helper Function: updateBlockTransmissions()

function updateBlockTransmissions($db, $api, $blockId, $date, $channel) {
    // 1. Get all transmissions in block (ordered by time)
    // 2. Recalculate start times
    // 3. Update local database
    // 4. Update Talpa (if talpa_transmission_id exists)
    // 5. Return results
}

Helper Function: syncTransmissionToTalpa()

function syncTransmissionToTalpa($api, $transmission) {
    if ($transmission['talpa_transmission_id']) {
        // PUT update
        return $api->updateTransmission($transmission['talpa_transmission_id'], $data);
    } else {
        // POST create
        $result = $api->createTransmission($data);
        return $result['id'];
    }
}

API Status Flow

pending → synced → pending → synced
   ↓         ↓         ↓         ↓
 CREATE    SYNC    UPDATE    RE-SYNC

Status Betekenis:

pending: Lokale wijziging, nog niet gesynchroniseerd
synced: In sync met Talpa
error: Synchronisatie gefaald

Edge Cases

1. Talpa Transmission ID Ontbreekt

Situatie: Oude data zonder talpa_transmission_id Oplossing: Behandel als nieuwe transmission (POST)

2. Talpa Update Faalt

Situatie: PUT request faalt (transmission bestaat niet meer in Talpa) Oplossing:

Zet talpa_transmission_id op NULL
Zet status op 'pending'
Bij volgende sync: POST nieuwe transmission

3. Blok Overlap

Situatie: Transmission verplaatsen veroorzaakt overlap Oplossing: Validatie blijft zoals nu (reject met error)

4. Overnight Blocks

Situatie: Blok loopt over middernacht (bijv. 23:30 - 02:00) Oplossing: Bestaande logica blijft werken (al geïmplementeerd)

Testing Scenario's

Test 1: Nieuwe Transmission Sync

Maak nieuwe transmission aan
Sync block
Verify: talpa_transmission_id is gevuld
Verify: api_status = 'synced'

Test 2: Update Transmission

Maak en sync transmission
Verplaats transmission naar andere tijd
Verify: Talpa is geüpdatet (PUT call)
Verify: Andere transmissions in blok zijn ook geüpdatet

Test 3: Insert at Position

Maak blok met 3 transmissions (alle synced)
Insert nieuwe transmission op positie 2
Verify: Nieuwe transmission is aangemaakt in Talpa
Verify: Transmissions 2 en 3 zijn geüpdatet in Talpa

Test 4: Cascade Update

Maak blok met 5 transmissions
Verplaats transmission 2 naar latere tijd
Verify: Transmissions 3, 4, 5 hebben nieuwe starttijden
Verify: Alle updates zijn naar Talpa gestuurd

Test 5: Error Recovery

Maak transmission met talpa_transmission_id
Simuleer Talpa error (transmission bestaat niet)
Verify: talpa_transmission_id wordt NULL
Verify: Status wordt 'pending'
Re-sync: nieuwe transmission wordt aangemaakt

Migratie Strategie

Voor Bestaande Data

-- Optioneel: Probeer transmission_id uit api_response te extracten
UPDATE transmissions 
SET talpa_transmission_id = JSON_EXTRACT(api_response, '$.id')
WHERE api_status = 'synced' 
AND api_response IS NOT NULL
AND JSON_VALID(api_response);

Note: Dit werkt alleen als api_response het id veld bevat.

Voordelen van Deze Aanpak

Incrementeel: Werkt met bestaande data
Robuust: Fallback naar POST als PUT faalt
Efficiënt: Direct updaten ipv wachten op sync
Consistent: Talpa blijft in sync met lokale planning
Traceerbaar: Duidelijke status en logging

Risico's en Mitigatie

Risico	Impact	Mitigatie
Talpa API rate limiting	Medium	Batch updates, retry logic
Netwerk failures	Medium	Error handling, status tracking
Data inconsistentie	Hoog	Transaction wrapping, rollback
Oude data zonder ID	Laag	Behandel als nieuwe transmission

Implementatie Volgorde

✅ Database migratie (nieuwe kolom)
✅ TalpaAPI uitbreiding (updateTransmission)
✅ sync_block.php update (save transmission_id)
✅ Helper functions (updateBlockTransmissions, syncTransmissionToTalpa)
✅ update_transmission.php update (cascade updates)
✅ insert_transmission_at_position.php update
✅ Testing en validatie
✅ Documentatie

Vragen voor Gebruiker

Moet er een retry mechanisme komen voor gefaalde Talpa updates?
Moeten we een audit log bijhouden van alle Talpa synchronisaties?
Wat gebeurt er als een transmission in Talpa is verwijderd maar lokaal nog bestaat?
Moeten we batch updates ondersteunen (meerdere transmissions in één API call)?

8.7 KiB Raw Blame History