Integrazione Sistemi Custom
L'integrazione sistemi custom collega applicazioni aziendali diverse — gestionali, ERP, CRM, piattaforme di fatturazione, software verticali — facendole comunicare in modo automatico. I dati fluiscono tra i sistemi senza inserimento manuale, senza export/import periodici, senza errori di trascrizione. Adatta quando le soluzioni off-the-shelf (Zapier, Make) non bastano: sistemi senza API, logica di business complessa, dati sensibili da non affidare a terzi.
Quando serve un'integrazione custom
La maggior parte delle PMI italiane usa 3-8 software diversi che non comunicano tra loro: il gestionale clinico non parla con la fatturazione, il CRM non aggiorna il magazzino, il software di cassa non sincronizza le presenze. Il risultato è lavoro manuale di allineamento, errori di trascrizione e dati sempre parzialmente aggiornati.
L'integrazione custom è la scelta giusta quando: trasferisci dati manualmente tra sistemi con cadenza quotidiana o più frequente; i sistemi non hanno webhook o API standard (gestionali legacy, software verticali di settore); la logica di trasformazione è complessa (regole di business, validazioni, scoring, lookup su tabelle); i dati sono sensibili e non devono transitare su piattaforme cloud terze; il volume è troppo alto per soluzioni no-code (migliaia di record al giorno).
L'integrazione custom non è necessaria quando: i due sistemi hanno già connettori nativi; Zapier o Make coprono il caso d'uso con un trigger semplice e poca logica; il trasferimento dati è occasionale (→ export manuale è sufficiente).
Tipologie di integrazione che realizziamo
Ogni integrazione ha un approccio tecnico diverso in base all'architettura dei sistemi coinvolti. Questi sono i pattern che usiamo più frequentemente:
API-to-API REST
Connessione diretta tra due sistemi che espongono API REST. Il connettore legge da un sistema e scrive nell'altro, gestendo autenticazione, rate limiting e retry automatici.
- Webhook per eventi real-time
- Polling schedulato per batch
- Gestione errori e dead letter queue
- Mapping e trasformazione campi
Database Bridge
Accesso diretto al database del gestionale (read-only su replica) per estrarre dati che non sono esposti via API. Tipico per software on-premise, SQL Server, MySQL.
- Replica read-only non invasiva
- Change Data Capture (CDC)
- ETL con trasformazioni custom
- Export su DB intermedio o API hub
Hub Multi-Sistema
Portale centralizzato che aggrega dati da N sistemi diversi in un unico punto di accesso. Ogni sistema ha il proprio connettore; il hub normalizza e rende disponibili i dati unificati.
- Aggregazione da 3+ sorgenti eterogenee
- Normalizzazione e deduplicazione
- KPI calcolati cross-sistema
- Interfaccia unica per gli operatori
ETL e Sincronizzazione
Pipeline Extract-Transform-Load per sincronizzare dati tra sistemi con frequenza definita. Ideale per reporting, analytics e allineamento batch notturno.
- Scheduling (cron, task queue)
- Trasformazioni e lookup su tabelle
- Idempotenza e upsert sicuri
- Log e alerting su anomalie
Middleware API
Layer intermedio che espone una nuova API unificata su più sistemi legacy. Altri applicativi consumano il middleware senza conoscere la complessità sottostante.
- API Gateway su sistemi legacy
- Endpoint REST o GraphQL
- Autenticazione centralizzata
- Caching e aggregazione risposte
Event-Driven (Webhook)
Architettura basata su eventi: quando accade qualcosa in sistema A, un webhook notifica sistema B che reagisce immediatamente senza polling periodico.
- Latenza vicina allo zero
- Firma e verifica payload
- Retry automatico su failure
- Idoneale per notifiche e trigger
Integrazione custom vs iPaaS (Zapier, Make, n8n): come scegliere
Non è una scelta di qualità — è una scelta di fit. Questa tabella orienta la decisione:
| Scenario | Soluzione consigliata | Perché |
|---|---|---|
| Sistemi SaaS con webhook nativi, logica semplice | Zapier / Make | Veloce, no-code, manutenibile da chiunque |
| Logica di trasformazione complessa, validazioni custom | Integrazione custom | Massima flessibilità, nessun limite di logica |
| Sistemi senza API (DB on-premise, legacy) | Database bridge custom | iPaaS non può accedere a DB dietro firewall |
| Dati sensibili (sanità, finanza, HR) | Integrazione custom on-premise | Dati non escono dall'infrastruttura aziendale |
| Volume alto, costo per operazione rilevante | Integrazione custom | Nessun costo variabile per task/record |
| 3+ sistemi con relazioni complesse tra dati | Hub multi-sistema custom | iPaaS multi-step diventa ingombrante e fragile |
Durante la discovery mappiamo il tuo ecosistema applicativo e identifichiamo l'approccio più adeguato — non forziamo un'integrazione custom se Zapier basta.
Caso d'uso reale (anonimizzato)
Descrizione anonimizzata di un progetto reale completato. Settore, architettura e stack sono reali — il nome del cliente non viene riportato per riservatezza.
Caso reale anonimizzato — Sanità / Gestione Ambulatoriale
Hub Multi-Sistema: 5 Gestionali → Portale Centralizzato
Problema: struttura sanitaria con 5 applicazioni separate non comunicanti — software clinico (SQL Server), sistema gestionale casse (SQL Server, istanza distinta), piattaforma di fatturazione elettronica (REST API cloud), software CRM pazienti (REST API), sistema di comunicazione WhatsApp Business (API Twilio). Ogni operazione richiedeva accesso parallelo a sistemi multipli; i KPI operativi non erano calcolabili in tempo reale perché i dati erano distribuiti su sorgenti eterogenee.
Soluzione: portale analitico centralizzato con 7 connettori Python Flask — un connettore dedicato per ogni sorgente dati, un livello di normalizzazione e un layer API unificato. I dati vengono aggregati, riconciliati e resi disponibili in un'unica interfaccia web. L'architettura è multi-app Flask su VM Azure Linux con accesso in sola lettura ai database on-premise e chiamate real-time alle API cloud.
Connettori implementati:
- SQL Server clinico (read-only, query ottimizzate per latenza)
- SQL Server gestionale casse (istanza separata, same host)
- FattureInCloud REST API (fatturazione, incassi, riconciliazione)
- REST API software CRM (anagrafica pazienti, appuntamenti)
- Twilio WhatsApp Business API (log comunicazioni, stato messaggi)
- SQLite locale (cache KPI, log operazioni, stato sync)
- Layer di riconciliazione cross-sorgente (scoring match pagamenti)
Stack: Python + Flask (multi-app) + SQL Server (2 istanze) + FattureInCloud API + REST API terze parti + Twilio WhatsApp Business API + SQLite + Azure VM Linux
Risultato: pannello operativo unico con KPI in tempo reale aggregati da tutte le sorgenti. Riconciliazione automatica incassi cross-sistema. Gli operatori accedono a un solo portale anziché aprire 5 applicazioni diverse per ottenere visibilità completa sulla giornata operativa.
Stack tecnico dichiarato
Usiamo questi strumenti per i progetti di integrazione. La scelta dipende dall'architettura dei sistemi da collegare e dai requisiti di latenza e volume:
Backend e Connettori
- Python + FastAPI / Flask per middleware
- Node.js per webhook real-time
- SQLAlchemy per accesso DB multi-engine
- requests / httpx per chiamate API REST
Database e Storage
- SQL Server, PostgreSQL, MySQL (read/write)
- SQLite per tracking locale e cache
- Redis per caching API ad alta frequenza
- S3 / Azure Blob per file e export
Infrastruttura
- Azure VM / AWS EC2 Linux
- Cron job / Celery per task schedulati
- Alerting via email/WhatsApp su errori
- Logging strutturato e monitoring
Come gestiamo un progetto di integrazione
Mappatura dell'ecosistema
Censimento di tutti i sistemi aziendali: versione, tipo di accesso disponibile (API, DB, export), volume dati, frequenza aggiornamento. Si identifica subito cosa può integrarsi facilmente e cosa richiede workaround.
Design dell'architettura
Scelta del pattern (punto-a-punto, hub, middleware), direzione dei flussi, gestione conflitti e errori. Si definisce quali dati devono essere real-time e quali possono essere batch. Preventivo a corpo con scope e timeline.
Sviluppo connettori e PoC
Primo connettore funzionante su dati reali per validare l'accesso e la qualità dei dati prima di procedere. Identificazione precoce di problemi di schema, permessi o volume.
Test e gestione eccezioni
Test con dati reali su tutti i casi limite: record mancanti, timeout API, cambiamenti schema, duplicati. Sistema di retry e dead letter queue per i messaggi falliti. Monitoring e alerting configurati.
Go-live e documentazione
Deploy in produzione con periodo di osservazione. Documentazione dei connettori, delle trasformazioni e delle procedure di manutenzione. Formazione del team tecnico del cliente se richiesta.
Analisi Sistemi Gratuita
30 minuti per mappare il tuo ecosistema applicativo, capire quali integrazioni sono fattibili e stimare i tempi. Nessun impegno, nessun costo.
Prenota l'Analisi Gratuita✓ 30 minuti ✓ Gratuita ✓ Preventivo a corpo scritto
Domande Frequenti sull'Integrazione Sistemi
Cos'è l'integrazione sistemi custom?
È lo sviluppo di connettori software su misura che fanno comunicare applicazioni aziendali diverse senza sostituirle. I dati fluiscono automaticamente tra i sistemi eliminando inserimenti manuali, export periodici ed errori di trascrizione. Si costruisce quando le soluzioni no-code (Zapier, Make) non bastano per complessità, volume o riservatezza dei dati.
Qual è la differenza tra integrazione custom e Zapier/Make?
Zapier e Make funzionano bene per integrazioni semplici tra sistemi SaaS con webhook nativi. L'integrazione custom è necessaria quando i sistemi non hanno API (accesso al database), la logica è complessa (trasformazioni, scoring, validazioni), il volume è alto (migliaia di record/giorno) o i dati sono sensibili e non devono passare per piattaforme terze. Come valutiamo l'approccio →
Posso integrare un software gestionale senza API?
Sì. Quando non esiste API, gli approcci sono: accesso read-only diretto al database (per sistemi on-premise con SQL Server, MySQL, PostgreSQL), RPA tramite interfaccia utente (per sistemi completamente chiusi), export schedulato elaborato da ETL. La scelta dipende dall'architettura del gestionale. Nella discovery verifichiamo quale approccio è fattibile per il tuo caso specifico.
L'integrazione modifica i miei sistemi esistenti?
No. I connettori Synaptica sono non-invasivi: si connettono tramite API ufficiali o in sola lettura al database, senza installare nulla nel software originale e senza modificarne il funzionamento. Il sistema che già usi continua a funzionare esattamente come prima. In caso di accesso al database, lavoriamo sempre su replica read-only.
Quanto tempo richiede un'integrazione?
Un'integrazione punto-a-punto tra due sistemi con API disponibili richiede tipicamente 3-6 settimane. Un hub multi-sistema (3+ gestionali, logica complessa, monitoring) richiede 8-16 settimane. I tempi dipendono dalla qualità della documentazione API e dalla disponibilità di un ambiente di test. Stimiamo dopo la mappatura dell'ecosistema. Processo dettagliato →
Cosa succede se uno dei sistemi integrati viene aggiornato?
Gli aggiornamenti dei sistemi sorgente possono rompere il connettore se cambiano lo schema del DB o il contratto API. Synaptica prevede monitoring attivo con alerting immediato su errori di connessione o anomalie nei dati. Per sistemi con versioning frequente, includiamo nel contratto una quota di manutenzione reattiva.