← Tutte le competenze

04

Integrazioni

Far parlare i sistemi che avete già, senza rifarli

Un’integrazione non fallisce quando il fornitore risponde «errore». Fallisce quando risponde «va bene» e non fa niente, o quando manda due volte lo stesso ordine. È da lì che partiamo.

Come colleghiamo due sistemi
  1. InventarioCosa espone ciascun sistema e — soprattutto — cosa non espone
  2. ContrattoSchema dei dati e casi d’errore concordati prima di scrivere il codice
  3. PonteLa traduzione fra i due modelli sta in un solo posto, non sparsa
  4. RipetibilitàOgni operazione può essere rifatta senza danno: prima o poi verrà rifatta
  5. Rete di sicurezzaUn controllo periodico riallinea quando l’altro lato tace
  6. AllarmeSe il collegamento si rompe lo sappiamo noi, non il vostro cliente

Prima si scrive il contratto

Ogni scambio ha uno schema dichiarato: quello che entra viene controllato prima di toccare qualsiasi cosa, quello che esce è documentato. Il vantaggio si vede il giorno dell’integrazione con un sistema di terzi: invece di scoprire i campi a forza di tentativi, c’è un documento che dice cosa arriva e cosa torna — e un test che fallisce se qualcuno lo cambia.

Doppioni, ritenta e rete di sicurezza

I messaggi arrivano doppi, arrivano in ordine sbagliato, o non arrivano. Ogni operazione che cambia lo stato è scritta per poter essere ripetuta senza danno, e ogni coda ha un numero massimo di tentativi con attesa crescente.

Quando il collegamento di un fornitore si dimostra inaffidabile non lo si supplica: gli si affianca un controllo periodico che riallinea lo stato. Costa poco e toglie una classe intera di telefonate.

Sistemi che non vogliono parlare

Gestionali con interfacce degli anni duemila, piattaforme che espongono solo una fetta di quello che serve, portali della pubblica amministrazione che accettano un file e basta: il lavoro è costruire uno strato che normalizza tutto questo in un modello unico, e chiudere le stranezze di ogni fornitore in un solo posto.

Chi comanda su ogni dato

Prima di scrivere una riga si decide, per ogni informazione, quale sistema è la fonte di verità: le giacenze le comanda il gestionale, gli ordini nascono dal negozio online, l’anagrafica appartiene a chi ha visto il cliente per primo. Non esiste una risposta valida per tutti — esiste quella giusta per come lavorate, e va scritta.

Quando questa decisione non viene presa, la prende l’integrazione da sola: vince l’ultimo che ha scritto, e sei mesi dopo nessuno sa più spiegare perché un prezzo è cambiato.

Quando l’altro lato non risponde

Un collegamento non fallisce quando il fornitore restituisce un errore: fallisce quando risponde "va bene" e non fa niente, o quando lo stesso ordine arriva due volte perché la conferma si è persa per strada.

Per questo ogni operazione che cambia lo stato è scritta per poter essere ripetuta senza danno, ogni coda ha un numero massimo di tentativi con attesa crescente, e quando i tentativi finiscono la cosa non muore in silenzio: qualcuno viene avvisato.

E quando il collegamento di un fornitore si dimostra inaffidabile, non lo si supplica: gli si affianca un controllo periodico che riallinea lo stato. Costa poco e toglie una classe intera di telefonate.

Sistemi vecchi, portali della pubblica amministrazione, file

Non tutto espone interfacce moderne, e va bene: si lavora con quello che c’è. Esportazioni programmate, cartelle sorvegliate, file posati su un server, in qualche caso lettura diretta della base dati con permessi di sola lettura.

Sono strade meno eleganti e perfettamente funzionanti, purché ci sia la stessa disciplina: un formato dichiarato, un controllo su quello che entra e un allarme quando il file di stanotte non è arrivato. La differenza fra un’integrazione e uno script è tutta lì.

Con cosa colleghiamo i sistemi

La tecnologia conta meno delle proprietà: ripetibile, sorvegliato, con un contratto scritto. Questi sono gli strumenti con cui le otteniamo.

  • Contratti

    • OpenAPI
    • Zod
    • JSON Schema
    • versionamento delle interfacce

    Quello che entra viene controllato prima di toccare qualsiasi cosa, e quello che esce è documentato. Cambiare un campo diventa una decisione consapevole invece di una sorpresa per chi sta dall’altra parte.

  • Trasporto

    • REST
    • webhook
    • code su PostgreSQL
    • n8n
    • file e cartelle sorvegliate

    Si sceglie il mezzo più semplice che regge il caso. Una coda con presa esclusiva evita che due esecutori facciano la stessa cosa; per i sistemi vecchi, una cartella sorvegliata vale quanto un’interfaccia moderna.

  • Affidabilità

    • operazioni ripetibili
    • ritenta con attesa crescente
    • riconciliazione periodica
    • traccia di ogni scambio

    Sono le quattro proprietà che distinguono un ponte da uno script. La riconciliazione, in particolare, è quella che vi salva quando il fornitore ha un problema e non ve lo dice.

  • Sorveglianza

    • allarmi su flussi fermi
    • cruscotto degli scambi
    • notifiche su Telegram o email
    • registro degli errori

    Un’integrazione che si ferma in silenzio è peggio di una che non esiste: nessuno ricopia più a mano e nessuno sa che il flusso è fermo. L’allarme deve arrivare a una persona, non a un registro che nessuno legge.

Portfolio

Cosa abbiamo fatto, progetto per progetto, su questa competenza.

Manora

API di una piattaforma blockchain

  • API documentate con controllo dei dati in ingresso, limiti di frequenza e metriche esposte per il monitoraggio.
  • Un processo separato segue la catena blocco per blocco, ricostruisce transazioni e saldi in PostgreSQL e riparte da dove si era fermato.
  • Notifiche in più lingue verso l’app, generate dagli eventi letti dalla catena invece che dal percorso di scrittura.
  • Node.js
  • PostgreSQL
  • Redis
  • OpenAPI
  • Prometheus

BigFishIta

API pubbliche e integrazione con LinkedIn

  • API di sola lettura per contenuti e anagrafica, con chiave per azienda: automazioni esterne leggono senza che si apra il database.
  • Integrazione con la piattaforma di pubblicazione social: messaggi in ingresso gestiti nei due formati che il fornitore alterna, più un controllo ogni cinque minuti che riallinea stato e commenti quando il collegamento tace.
  • Coda di lavori in PostgreSQL con presa esclusiva e ritenta, svuotata sia a intervalli sia subito dopo ogni inserimento.
  • Next.js
  • PostgreSQL
  • webhook
  • cron

CocoonServer

Console di gestione per istanze Odoo

  • Ogni rotta protetta da un controllo di autorizzazione unico e tipizzato: l’autenticazione non si riscrive a mano in ogni punto, quindi non si può dimenticare.
  • Operazioni lunghe trasmesse al browser mentre avvengono, invece di una richiesta che scade nel silenzio.
  • Next.js
  • Prisma
  • API Kubernetes
  • SSE

Ti serve questo?

Raccontaci il problema e vi diciamo come lo affronteremmo — e se non è il caso di farlo, ve lo diciamo lo stesso.

Parliamone