Middleware: quando serve (connettore, no-code o su misura)

Un middleware serve quando i sistemi da collegare diventano quattro o più, oppure quando anche un solo flusso deve reggere picchi di traffico ed errori temporanei senza perdere dati. Con due software e un flusso standard di solito basta un connettore pronto. In mezzo ci sono le piattaforme di integrazione no-code, che sono già un middleware in affitto.

Cos’è un middleware, in parole semplici?

È un software che sta in mezzo agli altri. Riceve i dati da un sistema e li consegna ad altri sistemi, dopo averli tradotti nel formato che ciascuno si aspetta. Invece di collegare ogni programma con ogni altro, ciascuno si collega al middleware. Il termine è largo: Red Hat, che ne vende, ricorda che è in uso dalla fine degli anni Sessanta per componenti molto diversi. Qui parliamo del middleware di integrazione, quello che fa passare ordini, anagrafiche, giacenze e documenti tra i software aziendali.

Per una PMI le strade concrete sono tre:

• Il connettore pronto collega due software precisi, spesso tramite un’app del loro marketplace. Serve quella coppia e basta, quindi non è un middleware in senso stretto.
• La piattaforma di integrazione, detta anche iPaaS (integration platform as a service): un servizio cloud in cui si costruiscono i flussi con blocchi già pronti. Zapier, Make, n8n e Power Automate sono gli esempi più noti.
• Il middleware su misura è un piccolo servizio scritto per la vostra azienda, che gira su un server o nel cloud e usa le API dei sistemi, cioè le porte d’accesso che ogni software apre agli altri programmi.

Se vi servono le basi su API e webhook, partite dalla guida su come far comunicare due software diversi.

Quando i collegamenti diretti smettono di reggere?

Quando i sistemi superano i tre e i flussi aumentano. Con n sistemi collegati ognuno con ognuno, i collegamenti possono arrivare a n × (n-1) / 2. Con un punto centrale ne basta uno per sistema:

Con tre sistemi il punto centrale non fa risparmiare nessun collegamento. Da quattro in su la differenza cresce in fretta. Per chi vende online otto sistemi non sono un caso estremo: ecommerce, gestionale, CRM, magazzino, corriere, marketplace, email marketing, fatturazione elettronica.

Lo stesso conto vale per le traduzioni tra formati di dati. Gregor Hohpe e Bobby Woolf lo mostrano nel catalogo Enterprise Integration Patterns: se sei applicazioni si scambiano dati in entrambe le direzioni servono 30 traduttori diretti, contro 12 se ognuna traduce da e verso un modello di dati comune. Con due applicazioni il modello comune ne richiede di più, 4 contro 2. Con tre si pareggia: 6 in entrambi i casi.

Altri indizi, come numeri che cambiano da un sistema all’altro o errori su ordini e giacenze che si ripetono, li trovate nei segnali che i software aziendali non stanno comunicando.

Cosa fa un middleware che un collegamento diretto non fa?

Gestisce quello che succede quando le cose non vanno lisce. Un collegamento diretto di solito copre il caso in cui entrambi i sistemi sono accesi e i dati sono puliti. Un buon middleware aggiunge queste funzioni:

• Trasforma i dati. Codici articolo diversi tra sito e gestionale, unità di misura, aliquote IVA, formati di date e indirizzi: le tabelle di corrispondenza stanno in un posto solo.
• Mette i messaggi in coda. Una coda è una lista d’attesa: il middleware accetta subito l’evento e lo elabora quando può. Shopify concede cinque secondi per rispondere a un webhook e suggerisce una coda per reggere i picchi. Senza risposta, o con un errore, ritenta 8 volte in 4 ore, poi può cancellare la sottoscrizione. Stripe consiglia la coda per i picchi di inizio mese, quando si rinnovano gli abbonamenti.
• Riprova con attese crescenti. Un errore temporaneo, come la rete che cade o un servizio sovraccarico, spesso si risolve da solo. La guida di Microsoft sui ritentativi suggerisce di riprovare con intervalli via via più lunghi e di fermarsi subito quando l’errore non è temporaneo, per esempio un dato sbagliato.
• Evita i doppioni. Un ritentativo può eseguire due volte la stessa operazione: Microsoft cita l’addebito su una carta di credito. Shopify e Stripe avvertono che lo stesso evento può arrivare più volte. Il middleware registra gli identificativi già elaborati e scarta le ripetizioni, così ripetere un’operazione non cambia il risultato (in gergo, idempotenza).
• Mette da parte i messaggi che non riesce a consegnare. Hohpe e Woolf lo chiamano dead letter channel, il canale dei messaggi non recapitabili: un archivio dove i casi da esaminare a mano restano in attesa invece di perdersi.
• Registra e avvisa. Ogni passaggio finisce in un registro (log) consultabile. Microsoft consiglia di segnalare come errore solo il fallimento dell’ultimo tentativo, per non sommergere di avvisi chi li deve leggere.
• Riconcilia. A intervalli regolari rilegge i dati dai sistemi e recupera quelli persi. Shopify lo raccomanda esplicitamente, perché la consegna dei webhook non è sempre garantita.

Connettore, no-code o su misura: quale scegliere e quanto costa?

Dipende soprattutto da quanti sistemi collegate e da quanto vi costa un errore. Le fasce di investimento qui sotto vengono dalla nostra Flow Audit, la diagnosi gratuita dei processi di DigiFluss. Sono indicative: il preventivo arriva dopo l’analisi, e la fascia dipende dalla complessità del processo più che dallo strumento.

I canoni delle piattaforme dipendono dall’uso. Al 2 ottobre 2026, con fatturazione annuale e IVA esclusa, Make Core costa 9 dollari al mese per 10.000 crediti (10,59 pagando mese per mese; prezzi visti dall’Italia), Zapier Professional 19,99 dollari al mese per 750 task e n8n Starter 20 euro al mese per 2.500 esecuzioni. Il consumo si misura in modo diverso: su Make ogni azione di un modulo vale un credito, su n8n conta l’esecuzione completa del flusso.

Il middleware su misura ha costi ricorrenti diversi. La coda di solito pesa poco: su Amazon SQS, il servizio di code di AWS, ogni operazione conta come una richiesta (per messaggi fino a 64 KB) e il primo milione di richieste al mese è gratuito per tutti i clienti. Un esempio con numeri ipotetici: 10.000 ordini al mese, ciascuno con tre operazioni (invio, lettura e cancellazione del messaggio), fanno 30.000 richieste, ben sotto la soglia gratuita. Contano però anche le letture che trovano la coda vuota, da non ripetere di continuo. La voce che pesa è la manutenzione. Secondo una stima classica dell’ingegneria del software (Robert Glass, IEEE Software, 2001), lungo la vita di un programma assorbe in media il 60% del costo complessivo. Le API dei sistemi collegati cambiano versione, e qualcuno deve adeguare il codice.

Se il gestionale è installato su un server in azienda, ogni servizio in cloud ha bisogno di un ponte. Per Power Automate e Logic Apps, Microsoft offre il gateway dati locale: un’applicazione Windows installata in sede che apre solo connessioni in uscita verso il cloud, senza porte aperte in entrata. Un middleware su misura in cloud può usare un piccolo agente con lo stesso principio.

Le piattaforme no-code gestiscono già gli errori?

In parte sì. Molte protezioni però vanno attivate a mano e hanno limiti legati al piano.

• Make può salvare le esecuzioni incomplete, cioè i flussi interrotti da un errore, e ritentare da solo quelle bloccate da problemi di connessione, tempo scaduto o limiti di chiamata: fino a otto tentativi, l’ultimo 7 ore e 51 minuti dopo l’esecuzione originale. Il salvataggio però è disattivato di default e va acceso scenario per scenario. Gli altri errori vanno di norma risolti a mano.
• Zapier, con la funzione Autoreplay, riesegue in automatico i flussi finiti in errore. Non è inclusa nel piano gratuito e va attivata, per tutto l’account o per il singolo flusso.
• n8n permette di impostare ogni nodo, cioè ogni passaggio del flusso, perché riprovi quando fallisce. A ogni flusso si può collegare un flusso di errore che manda un avviso via email o in chat.

Poi c’è la memoria. Make conserva i registri dettagliati delle esecuzioni per 7 giorni sul piano gratuito, 30 su Core, Pro e Teams, 60 su Enterprise. Sui piani cloud di n8n il massimo è 7 giorni con Starter e 30 con Pro. Se un errore emerge a fine trimestre, la traccia può non esserci più.

Per molti flussi di una PMI queste funzioni bastano, a patto che qualcuno le attivi e legga gli avvisi. Il su misura diventa interessante quando i volumi fanno crescere il canone o le regole diventano difficili da seguire in un editor a blocchi. Conta anche l’esigenza di conservare i registri per mesi o di tenere i dati su server scelti da voi.

Quali errori evitare con un middleware?

Quelli che nascono da decisioni rimandate, come chi controlla gli avvisi o cosa succede quando il punto centrale si ferma.

• Scegliere lo strumento prima di contare i flussi. Elencate sistemi, flussi, direzione e volumi. Con due sistemi una piattaforma pensata per decine di flussi è sprecata; con otto, un connettore per ogni coppia diventa ingestibile.
• Spostare nel middleware regole che spettano al gestionale. Se prezzi o sconti si calcolano nel middleware, avete due posti in cui cambiarli e prima o poi divergeranno. Le regole restano nel sistema che ha l’ultima parola su quel dato.
• Ritentare senza protezione dai doppioni. Se il sistema di destinazione non riconosce un ordine già importato, ogni nuovo tentativo rischia di crearne una copia.
• Avvisi che nessuno legge. Ogni avviso deve arrivare a una persona con nome e cognome, che sappia cosa fare e chi chiamare.
• Un punto centrale senza piano di ripresa. Se il middleware si ferma, si fermano tutti i flussi che ci passano. Decidete prima cosa succede ai messaggi nel frattempo e come si recuperano.
• Codice e accessi che non restano a voi. Per il su misura il contratto deve dire di chi sono codice e documentazione, e chi custodisce le credenziali. Sulle piattaforme, usate un account aziendale invece dell’account personale di chi costruisce i flussi.

Quando un middleware non serve?

Quando un collegamento diretto regge già volumi ed errori, o quando il problema sta altrove. Succede di solito in questi casi:

• Due sistemi e un flusso standard, con un connettore pronto per quella coppia che fa ciò che vi serve.
• Volumi bassi e nessuna urgenza. Poche decine di operazioni al mese, e un ritardo di un giorno non costa nulla.
• Un sistema in dismissione. Conviene aspettare quello nuovo e collegare lui.
• Il problema è nei dati o nel processo. Anagrafiche doppie o codici diversi per lo stesso prodotto: un middleware li sposta più in fretta senza correggerli. Lo stesso vale per le regole che nessuno ha mai scritto.

Per un caso concreto con fasce e tempi, la guida sull’integrazione tra CRM ed ERP mostra quando l’investimento si giustifica.

In sintesi

Un middleware serve quando i sistemi da collegare diventano quattro o più, o quando un flusso deve reggere picchi di traffico ed errori temporanei. Con due sistemi e un flusso standard basta di solito un connettore pronto; le piattaforme no-code coprono molti casi intermedi, purché ritentativi e avvisi siano attivati. Le fasce indicative della Flow Audit vanno da 2.500 a 7.500 euro per un’automazione semplice, da 7.500 a 25.000 per un processo integrato su più sistemi e da 25.000 in su per i progetti complessi. Vanno aggiunti canoni o hosting e la manutenzione, che lungo la vita del software pesa in media più dello sviluppo.

Fonti: fasce di investimento della Flow Audit DigiFluss (indicative, non preventivi); Red Hat, cos’è il middleware; G. Hohpe e B. Woolf, Enterprise Integration Patterns: Canonical Data Model e Dead Letter Channel; Shopify, webhook e consegna dei webhook; Stripe, webhook; Microsoft, schema dei ritentativi e gateway dati locale; Make, prezzi, esecuzioni incomplete e ritentativi automatici; Zapier, prezzi e riesecuzione dei flussi; n8n, prezzi, gestione degli errori e impostazioni dei nodi; Amazon Web Services, prezzi di Amazon SQS; R. L. Glass, Frequently Forgotten Fundamental Facts about Software Engineering, IEEE Software (2001). Dati verificati il 2 ottobre 2026.