Passepartout Mexal è il gestionale ERP di riferimento per migliaia di PMI italiane. Il suo punto di forza — la profondità funzionale costruita in trent'anni di evoluzione — è anche la sua sfida principale quando lo si vuole integrare con sistemi moderni come e-commerce headless o portali B2B custom. Dopo aver consegnato decine di integrazioni Mexal in produzione, abbiamo distillato i pattern che funzionano e quelli che falliscono.
L'architettura di base: middleware, sempre
Il primo errore — ricorrente — è tentare di parlare direttamente al database di Mexal o ai suoi servizi shaker da un e-commerce. Funziona finché non funziona più: prima release, primo aggiornamento, prima patch del vendor, e tutto si rompe.
L'architettura corretta prevede sempre un layer di middleware: un servizio dedicato che parla a Mexal con i protocolli ufficiali (Sprix, ShakerWS, file scambio) e che espone all'e-commerce (e a tutti gli altri sistemi) un'API moderna, REST/GraphQL, versionata, documentata. Quando Mexal cambia, cambi solo il middleware. Quando l'e-commerce cambia, cambi solo il middleware. È il classico pattern di disaccoppiamento, e nei nostri progetti riduce di 4-6x i costi di manutenzione a regime.
Listini: il labirinto
I listini in Mexal sono uno dei territori più articolati: listini base, scaglioni, sconti, listini speciali per cliente, condizioni quantitative. Il primo riflesso è replicare in toto la struttura sull'e-commerce. È sbagliato.
Il pattern che funziona: il middleware espone un endpoint `GET /price?product=X&customer=Y&quantity=Z` che ritorna il prezzo finale già calcolato applicando tutte le regole Mexal. L'e-commerce non sa nulla della complessità sottostante — chiede un prezzo, ottiene un prezzo. Tutta la logica di pricing resta dove è governata: in Mexal.
Giacenze: real-time o batch?
Domanda classica. La risposta dipende dal volume e dalla criticità dell'over-selling.
- Volumi bassi e prodotti unici: real-time. Mexal viene interrogata al checkout. Latenza accettabile (<500ms), zero disponibilità sbagliate.
- Volumi alti, prodotti commodity: batch ogni 5-15 minuti, con cache locale sull'e-commerce. Riduzione drastica del carico Mexal.
- Vendita multi-canale critica: sistema event-driven. Ogni movimento di magazzino in Mexal genera un evento (via webhook custom o polling tabella audit) che invalida la cache di tutti i canali.
Ordini in scrittura: la parte difficile
Leggere da Mexal è facile. Scrivere è dove i progetti muoiono. Tre regole che non tradiamo mai.
- Idempotenza. Ogni ordine ha un ID univoco lato e-commerce. Se la scrittura su Mexal va in timeout, riprovare con lo stesso ID non crea un duplicato.
- Coda persistente. Mai chiamare Mexal in modo sincrono dal checkout. L'ordine viene piazzato in una coda (Postgres, RabbitMQ, AWS SQS). Un worker dedicato lo processa con retry esponenziale.
- Reconciliation job notturno. Una routine che ogni notte confronta ordini lato e-commerce e ordini lato Mexal e segnala discrepanze. Catches the leaks.
Fatture e documenti contabili
La fatturazione resta sempre dentro Mexal. Non c'è alcun valore nel replicarla altrove. L'e-commerce o il portale B2B possono mostrare le fatture all'utente recuperandole dal middleware in PDF — il middleware le ottiene da Mexal solo quando richiesto, con cache breve.
Errori che vediamo ricorrere
- Connessione diretta DB: rompe ogni patch.
- Sincronizzazione master-master: i conflitti diventano ingestibili.
- Cache senza invalidazione esplicita: prezzi e giacenze sbagliate per ore.
- Niente monitoring: l'integrazione si rompe silenziosamente, ce ne si accorge dai clienti che chiamano.
La nostra posizione
Mexal è un eccellente backbone gestionale, ma non è un'API platform. Trattarlo per quello che è — un sistema profondo di registrazione contabile e amministrativa — e costruire intorno il livello di integrazione moderno, è la formula che fa girare le decine di e-commerce e portali B2B che 3-Way Software ha integrato negli ultimi anni. Vedi come lavoriamo sulla pagina dedicata all'integrazione Passepartout Mexal.