Procedure ottimali tecniche - API della piattaforma di marketing Eulerian

Procedure ottimali tecniche - API della piattaforma di marketing Eulerian




1. Autenticazione e sicurezza

token API

L'API di Eulerian utilizza un token Bearer passato nell'intestazione HTTP Authorization .
Buone prassi:
Authorization: Bearer <votre_token_api>

  • Non inserire mai il token direttamente nel codice sorgente. Utilizza una variabile d'ambiente o un sistema di gestione dei segreti (come Vault, AWS Secrets Manager, ecc.).
  • Limitare l'accesso ai token alle sole autorizzazioni strettamente necessarie (principio del minimo privilegio).
  • Non registrare le intestazioni di autorizzazione nei file di log dell'applicazione.

HTTPS richiesto

Tutte le richieste devono essere inviate tramite HTTPS.


2. Principi generali di integrazione

Struttura URL

Il dominio è specifico del tuo account Euleriano (ad esempio
https://<votre_domaine_eulerian>/ea/v2/<endpoint>
dem.api.eulerian.com ).

Intestazioni standard

Content-Type: application/json
Accept: application/json
Limitazione della velocità
Authorization: Bearer <token>



  • Rispetta i limiti di velocità imposti da Eulerian (fai riferimento alla documentazione contrattuale).
  • Implementare un meccanismo di backoff esponenziale in caso di risposta 429 Too Many Requests .
  • Evitate un'eccessiva parallelizzazione delle chiamate: preferite le code di elaborazione ordinate.

Idempotenza

  • Per le richieste di creazione di job, utilizzare un identificativo aziendale ( jobrun_id lato client) per evitare duplicati in caso di tentativi successivi.
  • Prima di crearne uno nuovo, verifica se esiste già un'offerta di lavoro simile.


3. Generazione di report in batch - Panoramica

La creazione di report in batch è il meccanismo principale per estrarre grandi volumi di dati analitici dalla piattaforma Eulerian. A differenza delle query sincrone (limitate a piccoli volumi), la creazione di report in batch opera in modo asincrono :
    Invii una richiesta di report → Eulerian crea un job e restituisce un jobrun_id .
    Si verifica periodicamente lo stato del lavoro ( tramite polling ).
    Una volta terminato il lavoro ( DONE ), è possibile scaricare il file dei risultati.

Quando utilizzare la creazione di report in batch?

Cas d'usage
Recommandation
Estrazione dei dati per oltre 7 giorni
È richiesto un lotto
Volume previsto: > 10.000 righe
Gruppo consigliato
Trattamenti programmati / ETL notturno
Lotto
Dashboard in tempo reale (< 1.000 righe)
API sincrona
Test/esplorazioni ad hoc
API sincrona


4. Ciclo di vita dei processi batch

[SUBMIT]PENDINGRUNNINGDONE
FAILED

EXPIRED
Statut
Description
PENDING
Lavoro in coda, non ancora elaborato
RUNNING
L'elaborazione è in corso da parte di Eulerian.
DONE
Report pronto per il download
FAILED
Errore durante l'elaborazione (vedere il campo error )
EXPIRED
Il file dei risultati non è stato caricato in tempo.
Periodo di conservazione dei risultati: i file generati da Eulerian sono disponibili per un periodo di tempo limitato (di solito da 24 a 72 ore). Scarica e archivia i risultati non appena lo stato è DONE .


5. Gestione dei sondaggi e dello stato di avanzamento

Endpoint di stato

Strategia di sondaggio consigliata
GET /ea/v2/report/batch/status.json?jobrun-id={jobrun_id}



Non effettuare mai polling eccessivamente aggressivo: ciò consuma inutilmente la tua quota di chiamate API.
Intervallo consigliato:
Temps écoulé depuis soumission
Intervalle de polling
0-2 minuti
Ogni 30 secondi
2 – 10 min
Ogni 60 secondi
10–60 min
Ogni 5 minuti
> 60 min
Ogni 15 minuti
Timeout massimo: definire un timeout complessivo (ad esempio, 4 ore). Trascorso tale periodo, il processo verrà considerato fallito e verrà inviata una notifica al sistema.
Implementazione:
  • Memorizza in modo permanente (nel database o in un file) l' jobrun_id ) in modo che il polling possa riprendere dopo il riavvio dell'applicazione.
  • Non iniziare un nuovo lavoro se un lavoro identico è già in corso ( PENDING o RUNNING ).

Esempio di ciclo di polling (pseudocodice)

ATTENDRE 30 secondes
TANT QUE timeout non atteint :
statut = GET /batch/status.json?jobrun-id{jobrun_id}
SI statut == DONE → télécharger résultat → FIN
SI statut == FAILED → logger erreur → FIN
SI statut == EXPIRED → relancer job → FIN
ATTENDRE intervalle_adaptatif()
7. Recupero ed elaborazione dei risultati
SINON → alerter équipe ops




Scarica l'endpoint

La risposta contiene il file direttamente per lo streaming oppure un URL per il download temporaneo.
GET /ea/v2/report/batch/download.json?jobrun-id={jobrun_id}


Scaricare le migliori pratiche

  • Trasmetti in streaming il download anziché caricare l'intero file in memoria (i file possono raggiungere diverse centinaia di MB).
  • Archiviare il file originale prima di qualsiasi elaborazione (principio di idempotenza dell'elaborazione).

Elaborazione CSV

  • Specificare sempre la codifica UTF-8 all'apertura del file.
  • Gestisci le righe di intestazione in modo dinamico (le colonne possono cambiare).
  • Verificare il numero di colonne in ogni riga prima di inserire i dati nel database.
  • Gestisci esplicitamente i valori nulli/le stringhe vuote (non confonderli con 0 ).

Gestione di grandi volumi

Per file di dimensioni superiori a 100 MB:
  • Elabora riga per riga in streaming (non caricare mai tutto nella RAM).
  • Inserire i dati nel database in lotti da 1.000 a 5.000 righe (inserimento in blocco).
  • Implementare il recupero dagli errori con la marcatura dell'ultima riga elaborata.


8. Gestione degli errori

Codici HTTP da elaborare

Code
Signification
Action recommandée
200
Successo
Trattamento normale
400
Richiesta non valida
Registra la risposta, correggi le impostazioni
401
Token non valido/scaduto
Rinnova il token, avviso
403
Autorizzazioni insufficienti
Verifica i diritti del token
404
Offerta di lavoro non trovata
L'offerta di lavoro è scaduta o l'ID non è corretto.
429
Limite di velocità raggiunto
Backoff esponenziale (min. 60s)
500
Errore del server Euleriano
Riprova dopo un po' di tempo; contatta l'assistenza se il problema persiste.
503
Servizio non disponibile
Riprova con un ritardo, monitora lo stato euleriano

Strategia di riprova

Tentative 1 : immédiate
Tentative 2 : +5 secondes
Tentative 3 : +15 secondes
Tentative 4 : +60 secondes
Tentative 5 : +300 secondes
Non riprovare mai sugli errori
Au-delà : alerter et abandonner
400 , 401 , 403 (errori del cliente: correggere prima il problema).

Registrazione

  • Registra sistematicamente: timestamp, endpoint chiamato, codice HTTP ricevuto, job_id , durata della richiesta.
  • Non registrare mai il token API o i dati personali dell'utente finale.
  • Conserva i registri degli errori per almeno 30 giorni per facilitare il debug.


9. Lista di controllo per la distribuzione in produzione

Sicurezza

  • Il token API viene memorizzato in una variabile d'ambiente (mai codificato direttamente nel codice).
  • HTTPS forzato su tutte le chiamate
  • I log non contengono il token né i dati personali.

Robustezza

  • Riprova con backoff esponenziale implementato
  • Timeout globale per il polling definito (consigliato: 4 ore)
  • jobrun_id mantenuto per il ripristino dopo l'arresto anomalo
  • Verifica dello stato prima di riavviare lo stesso lavoro

Prestazione

  • Intervalli di date suddivisi in finestre di ≤ 90 giorni
  • Selezione delle colonne limitata al minimo indispensabile
  • Download in streaming (senza caricamento completo della memoria)
  • Inserimento nel database in batch (inserimento in blocco)

Monitoraggio

  • Avvisi relativi a offerte di lavoro FAILED o KILLED
  • Avvisi di errore per 401 / 403 (token scaduto)
  • Pannello di controllo per il monitoraggio dei tempi di elaborazione dei lavori
  • Archiviazione dei file grezzi prima dell'elaborazione

Test

  • Test con intervalli di date brevi prima di passare alla produzione
  • Validazione del formato CSV di output (numero di colonne, codifica)
  • Test del comportamento in caso di errore 429 (limitazione della frequenza)
  • Test di ripresa dopo interruzione durante le votazioni