La soluzione raccomandata è usare SAP Integration Suite su SAP BTP con un approccio API-first ed event-driven, governato centralmente fin dal primo progetto pilota. Questa combinazione produce integrazioni riusabili, riduce l’accoppiamento tra sistemi e comprime il time-to-value rispetto a un’integrazione punto a punto. Nella pratica, i primi passi sono tre: predisporre un sottoaccount dedicato, abilitare Integration Suite dal BTP Cockpit e configurare Cloud Connector o Destinazioni in base al tipo di connettività richiesta.
In breve:
- La crescita dei sistemi di integrazione rende vantaggioso un approccio API-first e event-driven, riducendo tempi e doppioni rispetto alle soluzioni punto a punto.
- La configurazione corretta del sottoaccount, dei servizi nel cockpit e dei connettori di rete è fondamentale prima di iniziare a sviluppare flussi di integrazione.
- Per integrare sistemi on-premise, il Cloud Connector è essenziale, mentre per ambienti cloud-only le destinazioni nel cockpit sono sufficienti e più semplici da gestire.
- La scelta tra API sincrone e Event Mesh deve basarsi sulla tipologia di dipendenza tra sistemi, preferendo il secondo per notifiche asincrone e maggiore scalabilità.
- Un approccio incrementale con analisi, pilota e rollout graduale aiuta a ridurre i rischi e a garantire una migrazione più stabile e controllata.
Indice
- Cos’è SAP Integration Suite e come si integra con SAP BTP
- Componenti chiave e casi d’uso tecnici
- Setup operativo passo-passo in SAP BTP: sottoconto, cockpit, provisioning
- Connettività ibrida: Cloud Connector, Destinazioni e gestione certificati
- Pattern architetturali e governance: API-first, event-driven, clean core
- Fasi di adozione e migrazione: roadmap incrementale per modernizzare l’integrazione
- Esperienza pratica GreenSharp e risorse per progetti BTP
- Raccomandazioni strategiche per CIO e responsabili tecnici
- Offerta GreenSharp: supporto per implementare SAP Integration Suite e SAP BTP
- Risorse ufficiali e documentazione utile
- Fonti
- Domande frequenti
Cos’è SAP Integration Suite e come si integra con SAP BTP
SAP Integration Suite è la piattaforma di integrazione nativa di SAP Business Technology Platform. Non è un singolo prodotto ma un insieme di servizi che coprono scenari applicativi diversi, dal collegamento tra sistemi SAP interni alla comunicazione con partner esterni e piattaforme non SAP.
I componenti principali che compongono la suite sono:
- Cloud Integration: motore di orchestrazione ed esecuzione flussi per scenari applicazione‑applicazione (A2A) e business‑to‑business (B2B).
- API Management: gestione, sicurezza e monitoraggio del ciclo di vita delle API esposte verso terzi o consumate internamente.
- Event Mesh: broker di messaggistica per architetture guidate da eventi e comunicazione asincrona.
- Integration Advisor: repository collaborativo per mappature B2B basate su standard di settore.
- Open Connectors: connettori predefiniti per centinaia di applicazioni SaaS di terze parti.
- B2B Add-on: gestione di scambi EDI e protocolli con partner commerciali.
La suite viene provisionata come servizio dal BTP Cockpit, dove si assegnano piani, entitlement e permessi a livello di sottoaccount. Questo aspetto operativo distingue Integration Suite da un middleware tradizionale installato on‑premise: qui il provisioning è quasi immediato, ma richiede una pianificazione preventiva di ruoli e quote.
Un approccio punto a punto, in cui ogni sistema parla direttamente con un altro tramite script o connessioni dedicate, funziona nei progetti piccoli ma degenera rapidamente quando i sistemi coinvolti superano la decina. SAP posiziona Integration Suite come piattaforma enterprise capace di centralizzare API, eventi e governance in un unico punto di controllo, inclusi strumenti di intelligenza artificiale e acceleratori predefiniti che velocizzano la costruzione dei flussi.
Componenti chiave e casi d’uso tecnici
Ogni componente della suite risponde a un problema tecnico specifico, e sceglierlo correttamente evita mesi di refactoring successivo.
Cloud Integration gestisce il mapping dei dati e l’orchestrazione dei flussi tra sistemi. È lo strumento giusto quando serve trasformare formati (IDoc, XML, JSON, EDI), applicare logiche di instradamento condizionale o orchestrare sequenze di chiamate multiple. Un caso tipico è la sincronizzazione ordini tra un ERP S/4HANA e un sistema di gestione ordini esterno, dove il flusso deve validare, trasformare e instradare il messaggio prima della consegna finale.
API Management entra in gioco quando bisogna esporre servizi in modo controllato. Le sue policy gestiscono autenticazione OAuth, rate limiting, quote per consumatore e trasformazione del payload senza toccare il backend. Per un’azienda retail che apre le proprie API di catalogo a partner wholesale, questo componente permette di applicare limiti di traffico diversi per ciascun partner senza modificare il sistema sorgente.
Event Mesh serve architetture in cui i sistemi devono reagire a eventi senza dipendere da chiamate sincrone bloccanti. Un magazzino che pubblica un evento di variazione stock, consumato in tempo reale da e‑commerce, sistema di allocazione e reportistica, è lo scenario da manuale: i pattern event‑driven riducono l’accoppiamento tra sistemi e migliorano la scalabilità rispetto a un ciclo di polling continuo.
Integration Advisor e Open Connectors accelerano l’avvio dei progetti con partner e SaaS. Il primo mette a disposizione mappature standard (EDIFACT, ANSI X12) già collaudate da altre implementazioni; il secondo offre connettori pronti verso applicazioni come piattaforme CRM o marketing automation, evitando di scrivere adapter custom da zero.

Un consiglio: prima di scrivere un solo flusso, mappa gli eventi di business che i tuoi sistemi generano davvero. Molti progetti scelgono Cloud Integration per tutto solo perché è il componente più familiare, e finiscono per simulare un comportamento event‑driven con polling continuo, sprecando risorse di calcolo e complicando il debugging.
Setup operativo passo-passo in SAP BTP: sottoconto, cockpit, provisioning
Prima di scrivere il primo flusso di integrazione, l’ambiente BTP va predisposto in modo ordinato. Ecco la sequenza che riduce gli errori di configurazione iniziale:
- Crea il sottoaccount dedicato. Scegli provider cloud (AWS, Azure, GCP) e regione in base a latenza e vincoli di residenza dei dati.
Separare i sottoaccount per ambiente (sviluppo, test, produzione) semplifica governance e controllo dei costi. - Abilita i servizi nel BTP Cockpit. Il cockpit è il centro di controllo per gestire sottoconti, istanze di servizio e ruoli: qui assegni entitlement per Integration Suite, definisci i ruoli utente e collegi il sottoaccount al piano di licenza corretto.
- Provisiona le istanze necessarie. Attiva Cloud Integration e API Management come istanze separate, ciascuna con il proprio piano di servizio; verifica subito le quote incluse nel contratto per evitare colli di bottiglia in produzione.
- Scegli il runtime corretto. Cloud Foundry resta l’opzione più diffusa per Integration Suite; Kyma (basato su Kubernetes) si adatta a scenari con microservizi custom; il runtime ABAP è pertinente solo se stai estendendo S/4HANA con logiche native.
- Verifica i diritti di accesso end‑to‑end. Testa che un utente con ruolo “Integration Developer” possa effettivamente creare, deployare e monitorare un flusso prima di coinvolgere il team allargato.
La configurazione standard prevista da SAP segue esattamente questa logica: sottoaccount, connettività tramite cockpit e contenuti predefiniti dal SAP Business Accelerator Hub per accelerare i primi flussi. Partire da un pacchetto di contenuti già pronto, anziché costruire ogni mappatura da zero, è spesso la scelta che fa risparmiare più tempo nelle prime settimane di progetto.
Connettività ibrida: Cloud Connector, Destinazioni e gestione certificati
Collegare sistemi on‑premise al cloud richiede un componente specifico che funga da ponte sicuro senza aprire porte in ingresso sulla rete aziendale.
Il Cloud Connector è un agente installato nella rete on‑premise che stabilisce un tunnel sicuro verso il sottoaccount BTP. La configurazione base segue questi passaggi:
- Installa il Cloud Connector su un server nella rete interna con accesso ai sistemi da esporre.
- Registra il connector al sottoaccount BTP tramite le credenziali dell’amministratore.
- Definisci i sistemi backend accessibili (mapping tra hostname interno e virtual host esposto).
- Crea le Destinazioni corrispondenti nel BTP Cockpit, specificando protocollo, autenticazione e proxy type.
Per gli scenari puramente cloud, dove non esiste alcun sistema on‑premise da raggiungere, le Destinazioni configurate direttamente nel cockpit sono sufficienti e riducono i punti di possibile guasto: installare un Cloud Connector in quel caso aggiunge complessità senza alcun beneficio.
La gestione di certificati e trust store resta il punto più critico nelle installazioni iniziali. Quando un flusso fallisce con errori di handshake TLS, la causa è quasi sempre uno tra questi tre problemi: certificato scaduto nel trust store del Cloud Connector, mismatch tra il certificato presentato dal backend e quello registrato nella Destinazione, o un’autorità di certificazione intermedia mancante nella catena. Verificare la catena di certificati con uno strumento come OpenSSL prima di aprire un ticket di supporto fa risparmiare ore di troubleshooting inutile.

Un consiglio: quando un flusso Cloud Integration risponde con errore 403 su una chiamata verso un sistema on‑premise, controlla prima lo stato di connessione del Cloud Connector nel cockpit. Nella metà dei casi il tunnel è semplicemente disconnesso, non è un problema di permessi come suggerisce il codice di errore.
Pattern architetturali e governance: API-first, event-driven, clean core
La scelta tra API sincrone e Event Mesh asincrono non è una preferenza stilistica: dipende dal tipo di dipendenza tra i sistemi. Se il chiamante ha bisogno di una risposta immediata per proseguire il proprio processo, serve un’API sincrona. Se invece un sistema deve solo essere informato che qualcosa è accaduto, senza bloccare nessuno in attesa di risposta, Event Mesh è la scelta corretta e riduce drasticamente il rischio di cascate di errori quando un sistema a valle è temporaneamente irraggiungibile.
Il principio del clean core guida le decisioni di dove collocare la logica personalizzata, come illustrato in questo case study su modelli event‑driven e uso di Event Mesh. Le customizzazioni specifiche dell’azienda vanno spostate fuori da S/4HANA e ospitate su BTP, come estensioni side‑by‑side. Questo mantiene il core SAP aggiornabile senza rischi di conflitto durante gli upgrade, principio richiamato esplicitamente nelle linee guida SAP su clean core e integrazione. Chi vuole approfondire le tecniche concrete per realizzare queste estensioni trova indicazioni pratiche nella guida alle estensioni SAP BTP.
Tre pratiche di governance meritano un posto fisso in ogni progetto:
- Versioning obbligatorio delle API, con deprecazione pianificata e comunicata ai consumer con almeno un ciclo di rilascio di anticipo.
- Catalogo centrale di riuso, dove ogni nuovo flusso o API viene registrato prima di iniziare lo sviluppo, per evitare duplicati.
- Policy di sicurezza uniformi su autenticazione e cifratura, applicate a livello di piattaforma e non caso per caso.
Definire indicatori chiari fin dall’inizio del programma aiuta a dimostrarne il valore ai livelli direzionali. Misurare il numero di integrazioni punto a punto eliminate e il tasso di riuso delle API resta uno degli indicatori più concreti per valutare se il programma di integrazione sta davvero riducendo la complessità del landscape, insieme al numero di incident mensili collegati a errori di integrazione e al tempo medio di onboarding di un nuovo scenario.
Fasi di adozione e migrazione: roadmap incrementale per modernizzare l’integrazione
Un progetto “big bang”, dove tutte le integrazioni migrano contemporaneamente su Integration Suite in un unico weekend, è quasi sempre la scelta più rischiosa. La roadmap che funziona meglio nella pratica segue quattro fasi distinte.
- Analisi del landscape esistente. Cataloga tutte le integrazioni attive, classificale per criticità e volume di traffico, e seleziona due o tre flussi a basso rischio come candidati pilota, evitando di partire da un processo mission‑critical.
- Pilot e validazione. Implementa i flussi pilota su Integration Suite in parallelo al sistema legacy, confronta i risultati per un periodo di osservazione definito e stabilisci criteri di successo misurabili prima del roll‑out esteso.
- Roll‑out graduale per ondate. Migra gruppi successivi di integrazioni, dando priorità a quelle con maggiore impatto sul time‑to‑value o maggiore fragilità nel sistema attuale, senza forzare tempistiche rigide su scenari complessi.
- Stabilizzazione operativa con supporto AMS. Un servizio di Application Management System monitora i flussi in produzione, gestisce gli incident e presidia le richieste di change, liberando il team di progetto per le fasi successive di migrazione.
Le competenze richieste in questa fase non sono solo tecniche. Serve qualcuno che sappia leggere i log di Cloud Integration, ma anche chi capisce il processo di business dietro ogni flusso per riconoscere un’anomalia prima che diventi un incident visibile agli utenti finali. Un caso concreto di questo approccio a fasi è descritto nella guida su come integrare un sistema OMS con SAP in quattro fasi, applicabile come schema anche ad altri scenari di modernizzazione.
Esperienza pratica GreenSharp e risorse per progetti BTP
GreenSharp accompagna aziende del settore lusso e retail nella progettazione e implementazione di piattaforme tecnologiche avanzate, tra cui SAP BTP e SAP Integration Suite, con un approccio che parte sempre da un assessment del landscape esistente prima di proporre l’architettura target.
I servizi tipici in questo tipo di progetto comprendono:
- Assessment del landscape, per mappare integrazioni esistenti, criticità e priorità di migrazione.
- Disegno architetturale, con scelta dei pattern (API-first, event-driven, ibrido) più adatti al contesto specifico.
- Implementazione di Integration Suite, dal provisioning iniziale ai primi flussi in produzione.
- AMS per operatività continuativa, con monitoraggio, gestione incident e supporto al change nel tempo.
Chi gestisce processi wholesale o omnicanale trova un esempio pratico e diretto nella guida su come integrare un CRM con SAP in sei fasi, pensata per team IT e decisori che devono valutare priorità e sequenza degli interventi.
Raccomandazioni strategiche per CIO e responsabili tecnici
Chi guida la strategia IT dovrebbe smettere di chiedersi se adottare Integration Suite e iniziare a pianificare come farlo, con un ordine di priorità chiaro. La sequenza corretta non è mai “prima la piattaforma, poi la governance”: è l’esatto contrario. Investire in governance, cataloghi di riuso e un minimo di AMS prima di lanciare una migrazione su larga scala evita che il nuovo ambiente si riduca a un’altra collezione di integrazioni scollegate, solo su un’infrastruttura diversa.
Le mosse concrete da avviare in poche settimane sono tre: un inventario completo delle integrazioni esistenti con relativa classificazione del rischio, un pilot che combini almeno uno scenario API sincrono e uno event‑driven, e un workshop interno per verificare quali competenze mancano davvero al team prima di scoprirlo a metà progetto. Chi salta questo passaggio iniziale, nella mia esperienza di analisi di progetti simili, è quasi sempre lo stesso che si ritrova a rifare l’architettura dopo dodici mesi.
— Silvia
Offerta GreenSharp: supporto per implementare SAP Integration Suite e SAP BTP
Offre supporto ai team IT in ogni fase del progetto di integrazione, dall’assessment iniziale del landscape fino alla gestione operativa continuativa tramite AMS, con un approccio che privilegia pattern API‑first ed event‑driven fin dal primo pilota.

Il vantaggio rispetto a un’implementazione gestita internamente senza esperienza pregressa su Integration Suite è la riduzione del tempo di apprendimento: vengono portati pattern già validati su progetti simili, evitando gli errori di configurazione più comuni nelle prime settimane, dalla scelta del runtime alla gestione dei certificati nel Cloud Connector. Per capire come strutturare architettura e strategia IT prima di avviare l’implementazione, la pagina Business Technology Architects descrive il modello di lavoro proposto. Chi vuole partire con un assessment del proprio landscape SAP può richiedere un primo confronto tecnico su questa base.
Risorse ufficiali e documentazione utile
Per configurazioni puntuali su Destinazioni e Cloud Connector, la documentazione SAP resta il riferimento più aggiornato e affidabile: la guida ufficiale su come configurare una Destinazione nel sottoaccount BTP copre passo per passo autenticazione, proxy type e trust store.
Per una panoramica completa dei componenti della suite, la pagina prodotto di SAP Integration Suite descrive capacità, licensing e integrazione con gli acceleratori predefiniti. Materiali pratici aggiuntivi si trovano nel manuale completo su Integration Suite pubblicato da SAP Press, utile per chi implementa i primi flussi in autonomia.
Fonti
- Configure destination in your SAP BTP subaccount (SAP Help)
- Updated CIO guide: SAP’s hybrid integration platform (Community SAP)
- SAP Integration Suite | Integration Platform as a Service
Domande frequenti
Cos’è SAP Integration Suite in relazione a SAP BTP?
È il servizio di integrazione nativo di SAP Business Technology Platform, provisionato tramite il BTP Cockpit e composto da moduli distinti per API, eventi e scenari B2B.
Serve sempre il Cloud Connector per integrare SAP BTP?
No, solo per collegare sistemi on‑premise: per scenari esclusivamente cloud le Destinazioni sono sufficienti e riducono i punti di guasto.
Meglio partire con API sincrone o con Event Mesh?
Dipende dal tipo di dipendenza: usa API sincrone quando serve una risposta immediata, Event Mesh quando i sistemi devono solo essere notificati senza bloccare il processo chiamante.
Quanto dura tipicamente un progetto pilota su Integration Suite?
Non esiste una durata fissa: dipende dalla complessità dei flussi scelti, ma un pilota ben definito su due o tre scenari a basso rischio permette di validare risultati prima di passare al roll‑out esteso.
Che ruolo ha l’AMS dopo la migrazione a Integration Suite?
L’AMS monitora i flussi in produzione, gestisce gli incident e presidia le richieste di change, garantendo stabilità operativa dopo la fase di migrazione. GreenSharp offre questo servizio come parte del proprio supporto continuativo.