Pillar page

Integrazione di sistemi aziendali

Colleghiamo ERP, CRM, sistemi contabili, paghe e personale, registri aziendali, Microsoft Graph, Salesforce, SAP. Integrazioni tramite API, code, ETL e webhook — con controllo qualità completo, audit trail e monitoring di produzione.

Un'azienda di medie dimensioni utilizza da una dozzina a diverse decine di applicazioni di business. Ognuna conserva frammenti degli stessi dati — cliente, fattura, dipendente, ordine. Senza integrazione, i dipendenti passano ore al giorno a reinserire, esportare e importare manualmente i dati tra i sistemi.

L'integrazione di sistemi non è un lusso — è il fondamento della trasformazione digitale. Con un livello di integrazione ben progettato: un cliente aggiunto in CRM appare nell'ERP senza intervento, una fattura emessa in contabilità aggiorna la dashboard finanziaria del CEO, lo stato di un ordine è coerente tra negozio online, magazzino e customer service.

Perché l'integrazione è difficile?

Ogni sistema ha il proprio modello di dati, il proprio nome per lo stesso campo, la propria sequenza di operazioni, i propri vincoli API (rate limit, latenza, errori transitori). Due sistemi possono sembrare „compatibili" in teoria, ma in pratica richiedono settimane di lavoro su mapping, trasformazioni, gestione di edge case e risoluzione di conflitti.

Il secondo livello di difficoltà è l'affidabilità di produzione. Un'integrazione che funziona correttamente in dev environment è circa il 30% del percorso. Il restante 70% è la gestione di situazioni eccezionali: il sistema esterno non è disponibile, ha cambiato il contratto API, restituisce dati inattesi, è arrivato un nuovo cliente nel CRM con caratteri che il vecchio ERP non gestisce. Ogni caso richiede analisi, un test e un alert quando si verifica.

Tipi di integrazione

Sei pattern fondamentali. Nella maggior parte dei progetti ne combiniamo diversi, scegliendo il metodo giusto per ogni caso.

REST API / GraphQL

Comunicazione sincrona tra applicazioni. JSON come formato di scambio, OAuth2/JWT per l'autorizzazione, OpenAPI/Swagger per la documentazione. La scelta più comune per i sistemi cloud moderni.

Code di messaggi

RabbitMQ, Redis Streams, Kafka — scambio asincrono quando il mittente non attende il destinatario. Perfetti per notifiche, eventi di business, operazioni a lunga durata. Garanzia di consegna + retry.

ETL / ELT

Caricamento batch di dati in un data warehouse (Snowflake, BigQuery, Redshift, PostgreSQL on-premise). Airflow o dbt come orchestratore, validazione qualità dei dati (Great Expectations), monitoring del lineage.

Webhook

Notifiche push da un sistema sorgente (Stripe, GitHub, Slack, Salesforce) verso la nostra applicazione. Verifica della firma HMAC, idempotenza, dead-letter queue per consegne fallite.

SOAP / XML

Sistemi enterprise legacy (SAP, Oracle, banking, assicurazioni) — supporto completo WSDL, validazione XSD, WS-Security. Adattatore verso protocolli moderni per il resto del sistema.

Database — replica, CDC

Change Data Capture (Debezium, AWS DMS) per replica streaming delle modifiche da un database sorgente a uno di destinazione. Replica logica PostgreSQL per alta disponibilità e reporting.

Sei sfide chiave di produzione

Le cose a cui prestiamo attenzione in ogni progetto di integrazione. La mancanza di uno qualsiasi di questi elementi = bomba a orologeria.

Idempotenza

Ogni richiesta eseguita più volte produce lo stesso risultato. Chiavi di idempotenza negli header, deduplicazione a livello applicativo, transazioni attorno alle operazioni critiche.

Retry e backoff

Gli errori di rete transitori sono la norma. Backoff esponenziale (1s, 2s, 4s, 8s…), jitter per evitare thundering herd, circuit breaker dopo N tentativi falliti.

Mapping e trasformazioni

Il sistema A chiama un campo "client_id", il sistema B "customerId", il sistema C "id_klienta". Catalogo di mapping centrale, trasformazioni in un unico posto, test per ogni trasformazione.

Eventual consistency

I dati in due sistemi non sono mai coerenti al 100% in tempo reale. Accettiamo latenza (tipicamente secondi), monitoriamo il drift, allertiamo su divergenze prolungate.

Audit e compliance

Ogni operazione di integrazione registra: chi/cosa/quando/da dove/verso dove, payload (anonimizzato se contiene PII), risultato. L'audit log soddisfa i requisiti GDPR e ISO 27001.

Scalabilità e costi

Le integrazioni crescono con il business. Scaling orizzontale (più istanze), rate limiting (protezione da richieste eccessive), monitoring dei costi per integrazione.

Come realizziamo un progetto di integrazione

  1. Discovery (1-2 settimane): mappatura degli attuali flussi di dati, identificazione della fonte di verità per ogni entità, raccolta dei contratti API, valutazione di rischi e dipendenze.
  2. Architecture design (1 settimana): scelta dei pattern (sync vs. async, push vs. pull, hub-and-spoke vs. point-to-point), schema dell'audit log, piano di monitoring.
  3. Pilota su una singola entità (2-3 settimane): realizziamo l'integrazione per un tipo di dato (es. clienti) end-to-end. Validazione dei contratti, test di carico, dry-run in ambiente di test.
  4. Estensione alle entità rimanenti (4-8 settimane): sincronizzazioni successive (fatture, ordini, prodotti) con lo stesso pattern. Ogni rilascio preceduto da Change Request e test di regressione.
  5. Migrazione dati storici (1-3 settimane): spostamento dei dati esistenti. Dry-run, audit, piano di rollback. Migrazione incrementale o in finestra di servizio.
  6. Hypercare (4 settimane in produzione): monitoring intensivo, risposta rapida agli incidenti, tuning degli alert. Dopo l'hypercare, transizione alla manutenzione standard.

Esempi di integrazioni realizzate

KRS + CRBR — RejestrFirm

Microservizio che collega i dati del Registro delle Imprese polacco (oltre 740k aziende) al Registro Centrale dei Titolari Effettivi. Smart caching (24h), dual-source con fallback automatico, oltre 15 endpoint REST. Utilizzato in processi KYC, verifica delle controparti e reporting di compliance.

SSO con più applicazioni

Piattaforma Keycloak centrale (realm eskom-ai) integrata con una dozzina di applicazioni client. OAuth2/OIDC + PKCE, social login (Google, Microsoft, Apple, Facebook), provisioning utenti, billing basato sull'utilizzo dei token LLM. Single sign-on su tutti i prodotti ESKOM AI.

Microsoft Graph — calendari, e-mail, OneDrive

Integrazione con Microsoft 365 per automazione del calendario (assistente IA che programma riunioni), invio di e-mail transazionali, archiviazione documenti. OAuth2 con permessi delegati, refresh token in Vault, monitoring dei rate limit dell'API Graph.

LLM Proxy — routing multi-provider

Coda centrale che collega più provider LLM (Anthropic, OpenAI, Ollama locale). Routing per task (piccoli — modello locale, complessi — Claude Opus), cache delle risposte, monitoring dei costi per progetto, fail-over tra provider.

Domande frequenti

Cosa significa integrazione di sistemi?
L'integrazione di sistemi è il processo di collegamento di due o più applicazioni affinché possano scambiare dati, attivare eventi tra loro e restare coerenti. In pratica: quando un cliente viene aggiunto in CRM, appare automaticamente in ERP; quando una fattura viene emessa in contabilità, i dati fluiscono verso CRM e analytics. Senza integrazione, l'azienda manipola i dati manualmente (esporti CSV, copia tra sistemi), il che produce errori, ritardi e costi.
Quali tecnologie di integrazione utilizzate?
La scelta tecnologica dipende dal contesto: REST API e webhook per sistemi cloud moderni, SOAP/XML per ERP/banking legacy, code di messaggi (RabbitMQ, Redis Streams, Kafka) per scambio asincrono, ETL/ELT per alimentare data warehouse, GraphQL quando il cliente vuole flessibilità. Spesso mescoliamo gli approcci — sincrono dove l'utente attende un risultato, asincrono dove conta il throughput.
Le integrazioni si rompono quando i sistemi sorgente vengono aggiornati?
È uno dei maggiori problemi nell'integrazione — ed è per questo che costruiamo adattatori con isolamento (anti-corruption layer). Un sistema esterno cambia contratto → cambia solo l'adattatore, il resto dell'integrazione resta invariato. Inoltre: i contratti sono versionati (v1, v2), i test di integrazione girano quotidianamente su sandbox API, gli alert Sentry/Wazuh scattano sui cambi di formato delle risposte. Il cliente viene a conoscenza di un problema prima che raggiunga gli utenti finali.
Quanto dura un'integrazione tipica?
Le integrazioni semplici (un sistema verso un altro, ~5 endpoint, sincronizzazione monodirezionale) vengono realizzate in 1-2 settimane. Le integrazioni complesse (sincronizzazione bidirezionale, una dozzina di entità, mapping, trasformazioni, deduplicazione) durano 4-8 settimane. Le integrazioni multi-sistema (hub-and-spoke) sono pianificate in fasi, fornendo valore di business in iterazioni di 2-3 settimane.
E i dati storici in una nuova integrazione?
Ogni progetto di integrazione include una fase separata di migrazione storica. Prima un'analisi completa: quanti record, quali tipi di dati, dove sono i duplicati, quali campi sono obbligatori vs. opzionali. Poi uno script di migrazione con dry-run, audit trail (cosa è stato spostato, cosa è stato scartato, perché) e piano di rollback. La migrazione avviene in una finestra di servizio o incrementalmente, a seconda del rischio di business.
L'integrazione deve funzionare 24/7?
Dipende dalla criticità di business. I processi online (pagamenti, autorizzazioni) richiedono alta disponibilità — li progettiamo con ridondanza (load balancer, istanze multiple, health check, auto-restart). I processi notturni (report, sincronizzazioni batch) possono girare in finestre di servizio. Classifichiamo ogni integrazione con uno SLA: tempo di risposta p95, downtime mensile accettabile, RTO/RPO.
Come monitorate le integrazioni di produzione?
Ogni integrazione emette metriche verso Prometheus (request rate, error rate, latenza p50/p95/p99), log verso un SIEM centrale (Wazuh), errori verso Sentry. Gli alert scattano su cali di throughput, picchi di error rate o timeout. Una dashboard mostra lo stato di tutte le integrazioni in un unico posto — l'operatore può vedere, ad esempio, che l'integrazione con il fornitore X ha un 3% di errori mentre il resto gira fluido.
E la sicurezza nelle integrazioni esterne?
Ogni integrazione usa il principio del minimo privilegio. Chiavi e token risiedono in HashiCorp Vault (non in file .env, non nel codice). La comunicazione è sempre su TLS 1.2+, i certificati vengono verificati (mai verify=False). I webhook in ingresso hanno verifica della firma HMAC. In caso di leak di un token — rotazione immediata, l'audit log mostra cosa è successo e quando.
In cosa l'approccio di integrazione di ESKOM AI differisce da un classico ESB (Enterprise Service Bus)?
Gli ESB classici (Mule, BizTalk, WebMethods) sono piattaforme monolitiche — costose in licenze e che richiedono un team dedicato. Il nostro modello: microservizi di integrazione, ogni integrazione come componente separato con proprio deployment e monitoring, infrastruttura basata su open source (FastAPI, RabbitMQ, Redis, PostgreSQL, Vault). Costi di licenza inferiori, manutenzione più semplice, nessun vendor lock-in. Per alcuni clienti è un argomento finanziario, per altri — strategico.
Vi integrate con sistemi del settore pubblico polacco (KRS, CRBR, KSeF, ePUAP)?
Sì. In produzione gestiamo un microservizio integrato con KRS e CRBR (rejestrfirm.eskom.ai — dati di oltre 740k aziende inclusi i titolari effettivi). KSeF (fatturazione elettronica polacca) — abbiamo componenti di integrazione pronti nel progetto Kontroling. ePUAP, e-consegne — disponibili tramite Microsoft Graph API e integrazioni dirette. Piena conformità con la legge polacca (GDPR, obblighi di reporting).

Hai un progetto di integrazione?

Iniziamo con un audit gratuito — mappando gli attuali flussi di dati, identificando i colli di bottiglia e proponendo un piano in fasi chiare.