SAP Integration Suite: decisioni e compromessi in produzione

SAP Integration Suite è la piattaforma di integrazione di SAP su SAP BTP: Cloud Integration (l'ex CPI) più API Management, Event Mesh, Integration Advisor, Open Connectors e gli strumenti per migrare da PI/PO. È il middleware di riferimento per i programmi S/4HANA in cloud e la via d'uscita da PI/PO, la cui manutenzione mainstream termina nel 2027. I ritardi nelle interfacce raramente dipendono dalla tecnologia. Dipendono da responsabilità poco chiare, da ipotesi non verificate sui sistemi legacy e da test pensati per essere superati invece che per trovare i guasti. Questa guida è per integration lead, architetti e programme manager. Spiega a che cosa serve ogni componente, contenuti standard contro sviluppo custom, la migrazione di PI/PO, i rischi legati ai sistemi legacy e ai test, e la governance dopo il go-live.

PI/PO ha il conto alla rovescia. SAP Process Integration e Process Orchestration 7.5 sono in manutenzione mainstream fino alla fine del 2027. La manutenzione estesa opzionale arriva fino alla fine del 2030, dopodiché il supporto SAP termina. L'architettura di riferimento per la migrazione di SAP descrive il percorso. Integration Suite include un'applicazione Migration Assessment che dimensiona ogni scenario PI/PO e strumenti di migrazione guidati da wizard in Cloud Integration. Si migri a ondate: prima i flussi SAP-to-SAP a basso rischio, nel mezzo B2B ed EDI, per ultimi i flussi d'ordine ad alto volume. Un cutover forzato sotto la pressione della scadenza richiede più tempo e costa di più.

1. Ondata 1Flussi SAP-to-SAP a basso rischioPrima dimensioni ogni scenario con Migration Assessment
2. Ondata 2B2B ed EDI
3. Ondata 3Flussi d'ordine ad alto volume
4. 2027Termina la manutenzione mainstream di PI/PO 7.5Fine anno. Pianifichi le ondate in modo da concluderle prima di questa data
5. 2030Termina la manutenzione estesa opzionaleFine anno. Poi termina il supporto SAP

Fonte: Date di manutenzione SAP e architettura di riferimento per la migrazione, verificate a ottobre 2026

Verifichi che cosa copre il suo contratto cloud. I contratti RISE e GROW di solito includono crediti SAP BTP che possono pagare Integration Suite. Confermi quale edizione e quali volumi di messaggi copre il suo diritto d'uso prima di confrontare Integration Suite con MuleSoft o Boomi soltanto sulle funzionalità. L'economia di una piattaforma già inclusa cambia il confronto.

L'AI arriva per gradi. Cloud Integration offre nella sua edizione Premium la generazione di flussi con AI generativa da metà 2024. Produce la struttura di un iFlow (passi, canali, sottoprocesso di eccezione), non i mapping né gli script. L'enhanced edition di SAP, lanciata a marzo 2026, aggiunge la generazione di flussi da testo e l'ottimizzazione degli script, e SAP aveva previsto Joule in Integration Suite in disponibilità generale nel terzo trimestre del 2026. Utile per i flussi standard. L'orchestrazione complessa con logica di business articolata richiede ancora architetti senior.

Integration Suite è un insieme di servizi. Usare quello giusto per ogni compito determina quanto regge il panorama applicativo.

Componente	Ruolo	Che cosa va storto se viene usato male
Cloud Integration (CPI)	Flussi di messaggi, instradamento e trasformazione; la scelta predefinita per la maggior parte degli iFlow	Se si ficca tutto in CPI, API ed eventi compresi, diventa difficile da supportare e da testare
API Management	Governa l'esposizione delle API: sicurezza, rate limit, analytics	Se lo si salta, le chiamate punto a punto si moltiplicano; la governance è difficile da introdurre a posteriori
Event Mesh	Messaggistica asincrona per trigger disaccoppiati	Le code non monitorate crescono in silenzio senza avvisare nessuno
Integration Advisor	Proposte di mapping per formati B2B come EDIFACT, X12 e IDoc	I team presumono una copertura alta; uno si aspettava l'80% e ha ottenuto circa il 40%
Open Connectors	Connettori predefiniti verso app cloud di terze parti	Le modifiche alle API esterne rompono i connettori in silenzio, a meno che qualcuno non li monitori
Migration Assessment e strumenti	Dimensionano e migrano gli scenari PI/PO	Trattati come una stima una tantum invece che come un vero piano di migrazione

I team che trattano Integration Suite come «CPI con qualche extra» spesso ignorano API Management ed Event Mesh. Funziona finché la complessità non presenta il conto. La mia guida a SAP CPI approfondisce Cloud Integration stesso.

I contenuti di integrazione SAP predefiniti sono davvero utili quando il processo è standard. Collegare S/4HANA a SAP Ariba o a SuccessFactors con processi standard è spesso una soluzione pulita. I processi reali raramente restano dentro le linee di riferimento di SAP.

Scelga i contenuti standard quando:

1. Lo scenario è SAP-to-SAP e vicino al processo di riferimento di SAP
2. Il flusso è semplice e per lo più a senso unico
3. Si può convivere con il mapping di SAP ed estendere solo tramite le exit previste

Scelga lo sviluppo custom quando:

1. Anni di decisioni interne hanno allontanato il processo dal modello SAP
2. Entrano in gioco instradamento condizionale, logica a più passi o stranezze dei sistemi legacy
3. Una modifica pesante comprometterebbe l'allineamento al supporto SAP del pacchetto standard

Prenda la decisione nella fase di blueprint. Quando la si prende tardi, i team scoprono a metà progetto che un iFlow «standard» è stato modificato così tanto da perdere l'allineamento al supporto, e lo ricostruiscono sotto la pressione del go-live. Ho visto progetti perdere settimane perché i team davano per scontato che il contenuto standard assorbisse in una volta sola strutture anagrafiche custom, campi aggiuntivi e autenticazione legacy. Non è successo. L'analisi che spettava al disegno è avvenuta durante l'UAT.

Nei grandi programmi SAP l'integrazione è spesso la prima cosa a cadere tra un workstream e l'altro. Le interfacce attraversano i confini tra i team, ma nessuno è responsabile del coordinamento. Ho visto due team di progetto costruire integrazioni separate per lo stesso partner commerciale, puntando allo stesso endpoint, senza sapere l'uno dell'altro. Nessuno dei due se n'è accorto fino all'UAT. È un fallimento strutturale, non tecnico.

Imposti presto una governance centrale dell'integrazione:

1. Un backlog di integrazione condiviso e visibile a tutti i workstream
2. Un responsabile indicato per nome per ogni interfaccia, seguito per tutta la delivery
3. Punti di coordinamento tra i workstream prima di ogni rilascio importante
4. Una revisione delle dipendenze tra interfacce prima di qualsiasi impegno sul go-live, con endpoint e code condivisi messi in sequenza nel piano di cutover
5. Un deployment automatizzato tra gli ambienti, con le credenziali documentate per ciascun landscape

I problemi di integrazione più difficili raramente riguardano le piattaforme moderne. Riguardano i sistemi più vecchi al centro di processi critici.

Gli ERP legacy spesso non reggono chiamate sincrone concorrenti. Se si inviano cinque chiamate API in parallelo, il server rallenta, si blocca o perde dati in silenzio. L'integrazione asincrona aiuta solo se il sistema ricevente sa elaborare una coda, e molti non ne sono capaci.

Le incompatibilità di protocollo sono frequenti e vengono scoperte tardi. Si progetta con OAuth2 e REST; il sistema legacy parla SOAP con un timeout fisso di 30 secondi e gestisce male il rinnovo dei token.

In un caso presso un cliente, un flusso di middleware falliva ogni venerdì perché il token emesso da un sistema payroll di terze parti scadeva ogni settimana. Nessuno se n'è accorto fino al secondo ciclo di UAT. Stranezze come questa sono frequenti ed erodono i tempi.

La tabella elenca i rischi da verificare prima del design freeze.

Rischio	Problema tipico	Che cosa fare in fase di disegno
Limiti sincroni	Il legacy si blocca sotto chiamate parallele	Usare la messaggistica asincrona; scaglionare le chiamate con Event Mesh o Cloud Integration
Incompatibilità di protocollo	Il legacy rifiuta REST o OAuth, oppure va in timeout su SOAP	Confermare protocolli e timeout prima dell'inizio del disegno
Rate limit delle API	I batch job superano il throttling di terze parti	Applicare il throttling in API Management; aggiungere logica di attesa nell'iFlow
Scadenza dei token	I flussi falliscono in silenzio nelle finestre fuori orario	Pianificare i cicli di rinnovo e monitorare la scadenza
Formati rigidi	I payload dinamici rompono il parsing del legacy	Validare con campioni reali di produzione
Nessun fallback	I trasferimenti di file falliscono senza retry e i dati restano bloccati	Bufferizzare nel middleware; prevedere retry e alert negli iFlow

Per la versione cross-cloud di questi problemi, veda il mio articolo su perché l'integrazione tra ERP e Salesforce fallisce e come rimediare.

L'integrazione non si rompe nel modo in cui lo verificano i test funzionali. Fallisce sotto pressione di tempi, quando i job in background si sovrappongono e quando gli input arrivano in volume invece che uno alla volta. Un test funzionale dimostra che una transazione viene registrata e che un messaggio compare nel log. Non dimostra che cosa succede quando il primo payroll run invia una valanga di IDoc. In un progetto, un IDoc che sembrava pulito nei test di integrazione di sistema ha bloccato la coda quando sono arrivati i volumi reali del payroll. Solo il load test lo ha scoperto.

I test delle interfacce devono coprire:

1. Volumi di dati realistici con utenti concorrenti
2. Interruzioni del servizio e comportamento di ripristino
3. Timeout e retry tra middleware e back end
4. Batch job in esecuzione insieme alle chiamate in tempo reale
5. Chiusure mensili e altri periodi di picco

Gli ambienti di sviluppo sono puliti. Deadlock, race condition e throttling emergono in UAT e in pre-produzione, dove gli altri sistemi e le finestre batch sono attivi, quindi i load test vanno eseguiti lì. Si ripartiscano chiaramente le responsabilità: i team funzionali convalidano i risultati di business sull'intero flusso, i team di integrazione si occupano di log, retry e flussi di eccezione, e i responsabili di progetto confermano la copertura. La mia guida ai test di performance SAP tratta l'aspetto del carico.

Integration Advisor propone mapping per formati B2B strutturati. Con i partner che seguono convenzioni rigorose fa risparmiare tempo di configurazione reale. Per le integrazioni enterprise con sistemi legacy, campi custom, logica condizionale e regole non documentate è un punto di partenza.

Un team con cui ho lavorato si aspettava una copertura dei mapping dell'80%. La copertura effettiva è stata di circa il 40%. Il resto ha dovuto essere personalizzato, convalidato con il business e testato a mano.

Non risolve la logica di business accumulatasi informalmente nel corso degli anni (condizioni di pagamento, categorie di prezzo, convenzioni sulle unità), le regole condizionali basate sul contesto di business o le eccezioni fuori dal formato standard. Servono input funzionali. Senza di essi le interfacce risultano mappate dal punto di vista tecnico e sbagliate dal punto di vista logico in casi specifici.

Dopo il go-live l'integrazione si degrada quando la documentazione si allontana dalla realtà e la responsabilità non è formale. Una documentazione utile copre i mapping dei campi e la logica di trasformazione, e i dettagli di autenticazione come endpoint, rinnovo dei token e rotazione delle credenziali. Copre anche la gestione degli errori, le regole di fallback e i volumi attesi nelle finestre critiche come la chiusura mensile e il payroll. Il test: qualcuno che entra nel team di supporto la settimana prossima saprebbe risolvere un'interfaccia in errore usando solo la documentazione?

Ogni interfaccia, anche a basso volume, ha bisogno di un responsabile indicato per nome per monitoraggio, escalation e modifiche del ciclo di vita. Senza di lui, i guasti rimbalzano tra Basis, middleware e team funzionali mentre il business aspetta. Dopo l'hypercare il monitoraggio tende a spegnersi. Si prevedano revisioni periodiche dei log degli errori, un passaggio di consegne formale dal progetto al supporto e livelli di servizio concordati tra business e IT. Dietro molte registrazioni in ritardo, fatture mancanti e report finanziari disallineati che emergono settimane dopo il go-live c'è un'integrazione trascurata.

Che cos'è SAP Integration Suite e in che cosa si differenzia da CPI?

Cloud Integration, in passato SAP Cloud Platform Integration (CPI), è una delle funzionalità di Integration Suite. La suite aggiunge API Management per l'esposizione governata delle API ed Event Mesh per la messaggistica asincrona. Comprende anche Integration Advisor per le proposte di mapping B2B, Open Connectors per le app cloud di terze parti e strumenti di valutazione e migrazione per PI/PO. I team che la trattano come CPI con un nuovo nome spesso saltano API Management ed Event Mesh, e poi ne pagano il prezzo in lacune di governance.

Quando termina il supporto SAP per PI/PO?

SAP Process Integration e Process Orchestration 7.5 sono in manutenzione mainstream fino alla fine del 2027. I clienti possono richiedere la manutenzione estesa opzionale fino alla fine del 2030, dopodiché il supporto SAP termina. Integration Suite include un'applicazione Migration Assessment per dimensionare ogni scenario e strumenti di migrazione per spostare gli artefatti in modo semiautomatico. Si parta da un piano a ondate invece di aspettare la scadenza.

Quando conviene usare contenuti standard e quando lo sviluppo custom nell'integrazione SAP?

Si usino i contenuti standard quando lo scenario è SAP-to-SAP, vicino al processo di riferimento di SAP e relativamente semplice. Si costruisca custom quando il processo si è allontanato dal modello SAP, quando le stranezze dei sistemi legacy richiedono una gestione specifica o quando la logica condizionale e a più passi costringerebbe a modifiche pesanti del pacchetto standard. Si decida nella fase di blueprint: ricostruire un flusso standard modificato in eccesso sotto la pressione del go-live costa più di una build custom pulita.

Che cosa causa i guasti di integrazione SAP nei programmi complessi?

Soprattutto cause strutturali. Nessun responsabile indicato per monitoraggio e risoluzione degli errori, così i guasti rimbalzano tra i team. Due workstream che costruiscono integrazioni con un endpoint o una coda in comune senza saperlo. Sistemi legacy che non reggono chiamate concorrenti, scoperti solo sotto carico. E test che girano puliti in isolamento ma non simulano mai la sovrapposizione dei batch né i volumi di picco.

Come strutturare i test di integrazione per SAP Integration Suite?

Oltre ai test funzionali, si coprano volumi realistici come la prima chiusura mensile o il primo payroll run. Si testino i batch job in esecuzione insieme alle interfacce in tempo reale, il ripristino quando un sistema a valle non è disponibile e i rate limit di terze parti durante i job massivi. Si eseguano load e performance test in ambienti simili alla produzione, perché i sistemi di sviluppo puliti nascondono i problemi.

Come governare l'integrazione SAP dopo il go-live?

Si dia a ogni interfaccia un responsabile indicato per nome per monitoraggio, escalation e modifiche. Si tenga aggiornata la documentazione: mapping, autenticazione e rotazione delle credenziali, gestione degli errori e volumi attesi. E si costruisca un modello di supporto di lungo periodo, con revisioni periodiche dei log degli errori, un passaggio di consegne formale dal progetto al supporto e livelli di servizio concordati. L'integrazione che diventa invisibile viene trascurata.