Vai al contenuto principale
FromNine
Menu

Ingegneria

Integrazione di sistemi e API che mantengono i dati in movimento

Colleghiamo CRM, ERP, sistemi di gestione delle pratiche e piattaforme pubbliche con contratti, eventi e identità gestiti a regola d’arte: i dati fluiscono in modo affidabile, gli errori sono visibili e nuove funzionalità, IA compresa, si innestano in sicurezza.

Per imprese ed enti che devono collegare gestionali, partner e piattaforme nazionali, dalla fatturazione elettronica SDI alle piattaforme abilitanti della PA.

Parliamo del Suo progettoScopra il nostro approccio
Integrazioni e API: lo stack delle competenzeQuattro livelli sovrapposti in profondità. Dall’alto verso il basso: i consumatori come portali, app e agenti, l’API gateway con l’identità, la dorsale degli eventi e, alla base, i sistemi di riferimento.01Portali, app e agenti02API gateway e identità03Dorsale degli eventi04Sistemi di riferimento
  1. 01API contract-first con OpenAPI e AsyncAPI, versionate e documentate
  2. 02Eventi con ordinamento, idempotenza, gestione dei dead letter e replay
  3. 03Ogni flusso monitorato, ogni coda di errori affidata a un team designato

01 Problemi

I problemi di integrazione per cui veniamo chiamati

  1. 01

    Collegamenti punto a punto che nessuno osa toccare

    Decine di connessioni dirette tra CRM, ERP e sistemi su misura. Cambiare un campo significa testare dieci interfacce.

  2. 02

    Duplicati ed errori silenziosi

    Un nuovo tentativo genera un secondo ordine. Un messaggio non recapitato scompare. Gli utenti di business lo scoprono dai clienti.

  3. 03

    Ogni nuovo canale richiede nuovo lavoro di integrazione

    Il portale, l’app mobile e ora un assistente IA hanno bisogno degli stessi dati, e ciascuno riceve la propria estrazione.

  4. 04

    Gli scambi con la PA sono un progetto a sé

    Collegarsi a una piattaforma nazionale di scambio dati o a un sistema di identità digitale richiede ogni volta mesi di lavoro su sicurezza e accreditamento.

02 Ambiti di intervento

Che cosa realizziamo

  1. 01 Strategia e gestione delle API

    Progettazione API-first con contratti OpenAPI e AsyncAPI, una policy di versionamento, un gateway che la applica e un developer portal con cui i team trovano e riutilizzano ciò che esiste.

    Che cosa facciamo

    • Mappa del panorama API e delle responsabilità
    • Linee guida di progettazione e processo di revisione
    • Policy del gateway per sicurezza, quote e versionamento
    • Developer portal e catalogo delle API

    Che cosa riceve

    • Linee guida API adottate dai Suoi team
    • Configurazione del gateway come codice
    • Catalogo di API documentate

  2. 02 Integrazione a eventi

    Broker, change data capture e pattern outbox, con i dettagli che decidono se tutto funziona: ordinamento, consumatori idempotenti, gestione dei dead letter e replay.

    Che cosa facciamo

    • Modello degli eventi e convenzioni di denominazione
    • Outbox e CDC sui sistemi di origine
    • Idempotenza dei consumatori e garanzie di ordinamento
    • Code di dead letter con strumenti di replay

    Che cosa riceve

    • Dorsale degli eventi in produzione
    • Schema registry e regole di compatibilità
    • Runbook di replay e ripristino

  3. 03 Piattaforme di integrazione, scelte con onestà

    SAP Integration Suite, MuleSoft e i servizi di integrazione cloud-native hanno ciascuno il proprio spazio. Le diciamo quando un iPaaS conviene più del codice su misura, e quando no.

    Che cosa facciamo

    • Valutazione del middleware esistente
    • Scelta della piattaforma sulla base del costo totale di possesso
    • Mapping e connettori riutilizzabili
    • Migrazione dal middleware legacy

    Che cosa riceve

    • Registro della decisione sulla piattaforma di integrazione
    • Libreria di pattern di integrazione
    • Piano di migrazione delle interfacce esistenti

  4. 04 Identità e fiducia tra sistemi

    OAuth 2.0 e OpenID Connect, mutual TLS, identità da servizio a servizio e integrazione con le identità digitali di cittadini e imprese: itsme, DigiD ed eHerkenning, BundID, FranceConnect, Cl@ve, SPID e CIE.

    Che cosa facciamo

    • Architettura delle identità per utenti e servizi
    • Progettazione di token, scope e consenso
    • Supporto ad accreditamento e certificazione per l’identità digitale
    • Preparazione ai portafogli europei di identità digitale (EUDI Wallet)

    Che cosa riceve

    • Progetto delle identità e threat model
    • Integrazione dell’identità digitale in produzione
    • Identità di servizio e rotazione dei segreti operative

  5. 05 Interoperabilità con la pubblica amministrazione

    Collegamenti alle piattaforme nazionali di scambio dati, come il Federal Service Bus e MAGDA in Belgio, Digikoppeling e Common Ground nei Paesi Bassi, gli standard XÖV e FIT-Connect in Germania, la PDND in Italia e API Entreprise in Francia, oltre all’Once-Only Technical System dell’UE.

    Che cosa facciamo

    • Accreditamento presso il gestore della piattaforma
    • Mappatura sugli standard nazionali dei dati
    • Requisiti di sicurezza e di logging di ciascuna piattaforma
    • Progettazione dello scambio di evidenze secondo il principio «once only»

    Che cosa riceve

    • Collegamento certificato alla piattaforma di scambio
    • Documentazione delle mappature
    • Procedure operative concordate con il gestore

  6. 06 Visibilità operativa per gli utenti di business

    Un monitoraggio dei flussi leggibile dagli utenti di business, riconciliazione tra i sistemi e code di errori con un responsabile che le gestisce.

    Che cosa facciamo

    • Monitoraggio dei flussi a livello di business
    • Report di riconciliazione tra sistemi
    • Classificazione e instradamento degli errori
    • Allarmi per ciascun responsabile di flusso

    Che cosa riceve

    • Dashboard di integrazione per processo di business
    • Controlli di riconciliazione in produzione
    • Mappa delle responsabilità per ogni coda di errori

03 Architettura

Un’architettura di riferimento illustrativa

Dai sistemi di riferimento partono due percorsi. Le richieste sincrone passano per le system API e per un gateway che verifica identità, scope e quote. Le modifiche vengono pubblicate come eventi tramite outbox o change data capture, e i consumatori le elaborano in modo idempotente.

I messaggi non elaborati finiscono in una coda di dead letter con replay, non in un file di log. Una fascia di monitoraggio mostra ogni flusso in termini di business, così chi è responsabile di un processo vede quando si ferma.

Livelli del diagramma

Sistemi di riferimento
ERP, CRM e gestione delle pratiche mantengono l’autorità sui propri dati.
API sincrone
System API versionate dietro un gateway con OAuth 2.0, mTLS e quote.
Eventi
Outbox, broker, coda di dead letter e mapping della piattaforma di integrazione.
Consumatori
Portali, app, agenti, partner e piattaforme pubbliche di scambio, con identità digitale dove sono coinvolti i cittadini.
Esempio illustrativo

  1. Sistemi di riferimento

    • ERP, CRM e sistemi di gestione pratiche

  2. API sincrone

    • System API
    • API gateway: OAuth 2.0, mTLS, quote

  3. Eventi

    • Outbox e CDC
    • Event broker
    • Dead letter e replay
    • Mapping della piattaforma di integrazione

  4. Consumatori

    • Portali, app e agenti
    • Scambi con partner e PA
    • Identità: OIDC, mTLS, identità digitale

  5. Esercizio

    • Monitoraggio dei flussi, riconciliazione, code di errori con responsabile
API e dorsale degli eventi, fianco a fianco

Architettura illustrativa, non un sistema di un cliente.

Leggere il diagramma in forma testuale

Il percorso principale va dai sistemi di riferimento, attraverso system API versionate e un API gateway, fino a portali, app e agenti.

In parallelo, i sistemi di riferimento pubblicano le modifiche tramite outbox e change data capture su un event broker, che le recapita alle piattaforme di scambio con partner e PA e a una piattaforma di integrazione per i mapping. I messaggi non elaborati finiscono in una coda di dead letter con replay. Servizi di identità con OAuth, mTLS e identità digitale proteggono gli scambi con i partner.

Una fascia di monitoraggio alla base mostra stato dei flussi, riconciliazione e code di errori con un responsabile.

04 Considerazioni e limiti

Scelte progettuali e limiti

  • L’«exactly once» si progetta, non si configura

    Come lo affrontiamo

    Partiamo dal presupposto che i messaggi arrivino due volte o in disordine e progettiamo consumatori idempotenti, con chiavi e regole di ordinamento concordate per tipo di evento.

    Limiti e dipendenze

    Alcuni sistemi legacy non accettano chiavi di idempotenza né indicano che cosa hanno elaborato. Attorno a questi aggiungiamo la riconciliazione, invece di far finta di nulla.

  • Un iPaaS non è sempre la risposta

    Come lo affrontiamo

    Le piattaforme sono preferibili quando servono molti connettori e mapping standard; i servizi su misura quando la logica è complessa, i volumi elevati o le latenze stringenti. Documentiamo la scelta per ogni integrazione.

    Limiti e dipendenze

    I modelli di licenza cambiano. Una piattaforma economica oggi può diventare la voce più alta del Suo budget di integrazione, per questo modelliamo i costi su più anni.

  • Le piattaforme pubbliche hanno i loro tempi

    Come lo affrontiamo

    Prepariamo per tempo pratiche di accreditamento, evidenze di sicurezza e piani di test, e lavoriamo con il gestore della piattaforma fin dalla prima settimana.

    Limiti e dipendenze

    I tempi di certificazione e accreditamento li fissa il gestore, non noi. Pianifichiamo di conseguenza e Le indichiamo dove si collocano sul percorso critico.

  • I consumatori IA richiedono API circoscritte

    Come lo affrontiamo

    Agenti e assistenti ricevono API dedicate e dal perimetro definito, con limiti e audit log, non lo stesso accesso ampio dei servizi interni.

    Limiti e dipendenze

    Esporre un’API a un agente aggiunge rischio. Esaminiamo ciascuna API con il Suo team di sicurezza prima che entri in produzione.

05 Come lavoriamo

Come lavoriamo

Prima sciogliamo i nodi, poi costruiamo, e lasciamo ogni flusso con un responsabile.

  1. 01

    Mappare i flussi

    Ogni interfaccia, con il suo volume, lo storico dei malfunzionamenti e il responsabile di business.

    RisultatoPanorama delle integrazioni e classifica dei rischi

  2. 02

    Fissare le regole

    Linee guida API, convenzioni sugli eventi, modello delle identità e scelta della piattaforma.

    RisultatoLinee guida di integrazione e registri delle decisioni

  3. 03

    Migrare flusso per flusso

    Prima i flussi più rischiosi, con la riconciliazione attiva accanto alla vecchia interfaccia finché i numeri non coincidono.

    RisultatoFlussi migrati con evidenze di riconciliazione

  4. 04

    Gestire in modo visibile

    Dashboard per processo di business e code di errori con responsabili designati.

    RisultatoMappa delle responsabilità sui flussi e dashboard

06 Controllo umano

Dove il controllo resta alle persone

L’integrazione funziona senza presidio. La responsabilità di ciò che va storto, no.

  • Ogni coda di errori ha un responsabile

    I messaggi non elaborati vanno a un team che ne risponde, con il contesto e un comando di replay, non a un log condiviso.

  • Le modifiche ai contratti vengono revisionate

    Le modifiche non retrocompatibili ad API o eventi passano per una revisione con i consumatori prima di essere pubblicate.

  • I replay sono intenzionali

    Rielaborare messaggi in un sistema di riferimento è un’azione autorizzata, registrata con chi l’ha eseguita e perché.

07 Tecnologie

Tecnologie con cui lavoriamo

Piattaforme di integrazione
  • SAP Integration Suite
  • MuleSoft
  • Azure Integration Services
  • Servizi di integrazione AWS e Google Cloud
Eventi e streaming
  • Apache Kafka
  • RabbitMQ
  • Event broker cloud
  • Debezium per la change data capture
API
  • OpenAPI e AsyncAPI
  • API gateway e developer portal
  • GraphQL dove è adatto
  • Contract testing
Identità
  • OAuth 2.0 e OpenID Connect
  • Mutual TLS
  • Keycloak e identity provider cloud
  • Sistemi nazionali di identità digitale

La citazione di una tecnologia descrive la nostra esperienza di ingegneria. Non implica una partnership con il relativo fornitore né la sua approvazione.

08 Esempio

Un esempio illustrativo

Esempio illustrativo

Un servizio regionale collegato a PDND, pagoPA e App IO

01Situazione
Una Regione eroga contributi tramite un portale che chiede ai cittadini autocertificazioni su dati già presenti in altre banche dati pubbliche, e comunica gli esiti solo via PEC.
02Che cosa realizzeremmo
Accesso con SPID e CIE, lettura dei dati necessari tramite e-service della PDND, avvisi di pagamento pagoPA dove previsti e messaggi su App IO, tutto dietro un unico livello di integrazione.
03Dove decidono le persone
Gli istruttori confermano i dati che arrivano fuori dallo scambio automatico; finalità e livelli di accesso a ogni e-service sono autorizzati dall’ente prima dell’attivazione.
04Che cosa misureremmo
Quota di domande senza autocertificazioni, tempo dalla presentazione alla pratica completa, richieste di assistenza legate all’accesso.

09 Settori

Nel Suo settore

  • Pubblica Amministrazione

    Scambio di dati «once only» con le fonti autoritative, identità digitale per cittadini e imprese e il logging richiesto dalle piattaforme nazionali. Scopra il nostro lavoro per la pubblica amministrazione.

  • Manifattura e industria

    ERP, MES e portali fornitori collegati tramite eventi, così pianificazione, produzione e assistenza condividono lo stesso quadro.

  • Servizi finanziari

    Sistemi core, CRM e API dei partner collegati con identità robuste, audit log e una riconciliazione di cui l’amministrazione si fida.

Italia

Le piattaforme abilitanti italiane

Chi lavora con la PA italiana si confronta con un ecosistema preciso: la PDND per lo scambio di dati tra amministrazioni secondo le linee guida AgID sull’interoperabilità, SPID e CIE per l’identità digitale, pagoPA e App IO per pagamenti e comunicazioni, lo SDI per la fatturazione elettronica. A livello europeo, eIDAS 2 porta il portafoglio di identità digitale e la normativa su un’Europa interoperabile (Interoperable Europe Act) chiede di valutare l’interoperabilità dei nuovi servizi.

Trattiamo ogni piattaforma come un adattatore dietro contratti interni stabili: quando cambia una specifica si aggiorna l’adattatore, non i sistemi che lo usano.

Domande su integrazioni e API

Conviene usare una piattaforma di integrazione o sviluppare integrazioni su misura?

Entrambe le cose, per flussi diversi. Connettori standard, mapping e accreditamento dei partner favoriscono una piattaforma. I flussi ad alto volume, sensibili alla latenza o ricchi di logica favoriscono spesso servizi su misura. Decidiamo flusso per flusso e documentiamo il perché.

Integrate Salesforce, SAP e Odoo?

Sì, regolarmente, tra loro e con sistemi su misura e della PA. FromNine ha lo status di partner con tutte e tre le piattaforme (Salesforce Summit Partner, SAP Gold Partner, Odoo Gold Partner), quindi i nostri team di integrazione lavorano fianco a fianco con gli specialisti di piattaforma. Scopra il nostro lavoro di integrazione SAP.

Ci serve un’integrazione a eventi?

Quando più sistemi devono reagire alla stessa modifica, o quando occorre disaccoppiare i cicli di rilascio, gli eventi aiutano. Per una semplice richiesta e risposta tra due sistemi, spesso basta un’API. La maggior parte dei contesti usa entrambi.

Potete integrare i sistemi nazionali di identità digitale?

Sì. Integriamo i sistemi di identità digitale per cittadini e imprese e progettiamo in vista dei portafogli europei di identità digitale che gli Stati membri stanno introducendo in base a eIDAS 2. I requisiti di accreditamento variano da sistema a sistema e li pianifichiamo per tempo.

Abbiamo un middleware legacy. Dobbiamo sostituirlo?

Non tutto in una volta. Mappiamo ciò che vi gira sopra, spostiamo per primi i flussi più rischiosi o più costosi e manteniamo la riconciliazione finché ogni flusso migrato non ha dato prova di sé.

Porti l’interfaccia che si guasta più spesso

Le mostreremo come renderla osservabile, idempotente e con un responsabile chiaro, e che cosa servirebbe per fare lo stesso con le altre, insieme al Suo team IT.

Parliamo del Suo progettoScoprire il nostro approccio