Blu Pantheon
Автоматизация и RPA

Modello di integrazione

Architettura inbound e outbound, pattern sincroni e asincroni, garanzie di consegna, idempotenza, backpressure e budget di errore.

Questa pagina definisce come Blu Pantheon e i tuoi sistemi si parlano. Leggila prima di scrivere una riga di codice: le scelte descritte qui determinano affidabilità, costi operativi e facilità di diagnosi dell'integrazione.

I due canali

Inbound — dal tuo sistema verso Blu Pantheon

Il robot, il middleware o il backend aziendale chiama le API REST della piattaforma.

GET/identity/v1/clientsAPI Key

Esempio di chiamata inbound: elenco paginato dei clienti del progetto.

Caratteristiche:

  • Sincrono: la risposta contiene subito il risultato.
  • Autenticato con chiave API bp_live_xxxxxxxxxxxxxxxx.
  • Soggetto a limiti di frequenza con header X-RateLimit-Limit, X-RateLimit-Remaining, X-RateLimit-Reset.
  • Idempotente su richiesta per le scritture, tramite header Idempotency-Key.

Outbound — da Blu Pantheon verso il tuo sistema

Quando accade un evento, la piattaforma esegue una POST HTTPS verso l'endpoint registrato.

Richiesta outbound
POST /webhooks/blupantheon HTTP/1.1
Host: automation.acme.it
Content-Type: application/json
User-Agent: BluPantheon-Webhooks/1.0
X-BP-Event: session.handover.requested
X-BP-Delivery: 7c1f0f9e-4b2a-4e7c-9a10-2f5c8d3b6a41
X-BP-Timestamp: 1767225600
X-BP-Signature: t=1767225600,v1=9f2c...c41d

Caratteristiche:

  • Asincrono: l'evento viene consegnato dopo il fatto, non blocca la conversazione.
  • At-least-once: la stessa consegna può ripetersi. La deduplica è responsabilità del consumatore.
  • Non ordinato: due eventi vicini nel tempo possono arrivare invertiti.
  • Firmato: ogni corpo è autenticato con HMAC-SHA256.

Non usare il webhook come transazione

Il webhook notifica che qualcosa è accaduto. Se il tuo processo richiede una risposta che influenza la conversazione in corso, usa una chiamata inbound dal tuo sistema (o uno strumento dell'agente), non la risposta HTTP al webhook.

Flusso completo passo per passo

Scenario: un visitatore chiede di parlare con un operatore, il robot RPA apre un ticket nel gestionale e riporta il numero di pratica nella conversazione.

Il visitatore apre la conversazione

Il widget crea una sessione. La piattaforma emette session.created con sessionId, projectId e i metadati del canale.

L'agente AI gestisce la richiesta

L'agente risponde usando la knowledge base. Ogni messaggio genera eventi interni; non tutti sono esposti come webhook per evitare rumore.

Viene richiesto l'handover

Il visitatore chiede un operatore umano oppure l'agente rileva un'intenzione critica. La piattaforma emette session.handover.requested.

Blu Pantheon consegna il webhook

Viene eseguita una POST firmata verso https://automation.acme.it/webhooks/blupantheon. L'endpoint verifica la firma, controlla X-BP-Delivery contro le consegne già viste, accoda il messaggio e risponde 202 Accepted in meno di 200 ms.

Il robot preleva il messaggio dalla coda

L'orchestratore RPA assegna il messaggio a un robot disponibile. Il robot legge sessionId, clientId e la trascrizione sintetica dal payload.

Il robot opera sul gestionale

Il robot apre il gestionale, crea la pratica e ottiene il numero di protocollo (ad esempio PRT-2026-004512).

Il robot riporta l'esito via API

Il robot esegue una chiamata inbound autenticata per aggiungere una nota alla sessione e aggiornare i metadati con il numero di pratica. Usa un Idempotency-Key derivato da X-BP-Delivery per evitare duplicati in caso di riesecuzione.

Chiusura del ciclo

L'operatore vede la nota nella Console. Alla chiusura, la piattaforma emette session.closed e il robot archivia la pratica.

Sincrono contro asincrono

AspettoPattern sincronoPattern asincrono
Chi iniziaIl tuo sistemaBlu Pantheon
Tempo di rispostaDeve stare nel timeout HTTP del clientL'endpoint risponde subito, il lavoro prosegue in coda
Gestione picchiIl chiamante applica backoff sui 429La coda assorbe il picco
ErroriVisibili immediatamenteVisibili nei log consegne e nelle metriche della coda
Uso correttoLettura dati, scritture puntuali, verificheReazione a eventi, orchestrazione di processi lunghi

Regola pratica

Se l'operazione dura più di 2 secondi, rendila asincrona. Se dura più di 10 secondi, deve obbligatoriamente essere asincrona: il webhook andrebbe in timeout.

Garanzie di consegna

At-least-once

Ogni evento viene consegnato almeno una volta. Una consegna può ripetersi se:

  • il tuo endpoint risponde con un codice diverso da 2xx;
  • la risposta arriva oltre 10 secondi;
  • la connessione TCP o il handshake TLS falliscono;
  • un operatore esegue un replay manuale dalla Console.

Nessuna garanzia di ordine

Gli eventi non sono ordinati. Non assumere che session.created arrivi prima di session.message.created della stessa sessione. Per ricostruire l'ordine usa il campo createdAt del payload, non l'ordine di arrivo.

Riordino difensivo lato consumatore
function shouldApply(incoming, stored) {
  if (!stored) return true;
  return new Date(incoming.createdAt) > new Date(stored.createdAt);
}

Idempotenza

Meccanismi di idempotenza

ParametroTipoObblig.DefaultDescrizione
X-BP-Deliverystring (uuid)Sì—Identificativo univoco della consegna in ingresso. Salvalo e scarta le consegne già viste.
idstringSì—Identificativo dell evento nel payload. Stabile tra i ritentativi della stessa consegna.
Idempotency-KeystringNo—Header che invii tu sulle scritture inbound. Ripetendo la richiesta con la stessa chiave ottieni la stessa risposta senza creare duplicati.

Schema di deduplica consigliato: una tabella con delivery_id come chiave primaria, stato (received, processing, done, failed) e timestamp. Conserva i record almeno 7 giorni, cioè oltre la durata massima della catena di ritentativi.

Tabella di deduplica
CREATE TABLE bp_webhook_delivery (
  delivery_id   CHAR(36)     NOT NULL PRIMARY KEY,
  event_type    VARCHAR(64)  NOT NULL,
  event_id      VARCHAR(64)  NOT NULL,
  status        VARCHAR(16)  NOT NULL DEFAULT 'received',
  received_at   DATETIME(3)  NOT NULL,
  processed_at  DATETIME(3)  NULL,
  INDEX idx_event (event_id),
  INDEX idx_status_received (status, received_at)
);

Backpressure e code

Il tuo endpoint deve rispondere entro 10 secondi. Se il sistema a valle rallenta, non rallentare la risposta: accoda.

ComponenteResponsabilitàDimensionamento consigliato
Listener HTTPVerifica firma, deduplica, accoda, risponde 202Latenza p95 sotto 200 ms
CodaAssorbe i picchi, garantisce persistenzaCapacità pari a 30 minuti di picco
Worker / robotElabora, ritenta, marca il risultatoConcorrenza limitata dalle licenze RPA
Dead letter localeRaccoglie i messaggi non elaborabiliAllarme su qualsiasi elemento presente

Antipattern

Elaborare il gestionale dentro la richiesta HTTP del webhook. Il gestionale è lento e instabile: la richiesta andrà in timeout, Blu Pantheon ritenterà, e il gestionale riceverà la stessa operazione più volte in parallelo.

Timeout e budget di errore

ParametroValoreNote
Timeout di risposta webhook10 secondiOltre il quale la consegna è considerata fallita
Tolleranza timestamp firma5 minutiOltre la quale la richiesta va rifiutata
Tentativi di consegna5Immediato, 1 min, 5 min, 30 min, 2 h
Ritenzione dead letter30 giorniReplay manuale disponibile dalla Console
Timeout consigliato lato client inbound15 secondiCon 3 ritentativi e backoff esponenziale

Definisci un budget di errore esplicito: ad esempio, non più dello 0,5% di consegne fallite su finestra di 24 ore. Superata la soglia, l'integrazione va considerata degradata e va aperta una verifica. Vedi Osservabilità per le metriche.

Webhook, polling o batch?

CriterioWebhookPolling APIExport batch
LatenzaSecondiPari all'intervallo di pollingOre
Carico sulle APIMinimoAlto e costanteConcentrato
Complessità inizialeMedia (endpoint pubblico + firma)BassaBassa
Robustezza a disservizi del consumatoreAlta (ritentativi + dead letter)Alta (riprende da cursore)Alta
Richiede endpoint pubblicoSìNoNo
Ordine garantitoNoSì, se si usa il cursoreSì
Adatto a riallineamenti storiciNoSìSì
Costo per eventoBassoAltoMolto basso

Quando scegliere cosa

  • Webhook: reazione in tempo reale a eventi di business. È la scelta predefinita.
  • Polling API: quando non puoi esporre un endpoint pubblico (rete chiusa, vincoli di sicurezza), oppure per riconciliazione periodica dopo un disservizio.
  • Batch export: per popolamento iniziale, data warehouse, reportistica e analisi storiche.

Combinazione consigliata

Webhook per il tempo reale più un polling di riconciliazione ogni ora sulle ultime 6 ore. Il polling recupera qualunque evento perso senza generare carico significativo.

Polling di riconciliazione
curl -sS -G "https://api.blupantheon.com/identity/v1/events" \
  -H "Authorization: Bearer $BP_API_KEY" \
  -H "X-BP-Project: bp_proj_7f3a9c21" \
  --data-urlencode "since=2026-09-04T08:00:00Z" \
  --data-urlencode "limit=100" \
  --data-urlencode "cursor=$LAST_CURSOR"

Versionamento del contratto

Ogni payload contiene apiVersion. Le regole di compatibilità sono:

Tipo di modificaConsiderataPreavviso
Aggiunta di un campo opzionale nel payloadNon breakingNessuno
Aggiunta di un nuovo tipo di eventoNon breakingNessuno
Rimozione o rinomina di un campoBreaking90 giorni
Cambio di tipo di un campoBreaking90 giorni
Deprecazione di un eventoBreaking180 giorni

Parsing tollerante

Il tuo consumatore deve ignorare i campi sconosciuti e non fallire se ne compaiono di nuovi. Un parser rigido si rompe alla prima estensione non breaking.

Passi successivi

На этой странице