Architettura di integrazione: connettere SAP Sales Cloud V2 a S/4HANA Public Cloud

La risposta breve: Sales Cloud V2 e S/4HANA Public Cloud si integrano tramite SAP Integration Suite su BTP, con pacchetti di iFlow standard che SAP fornisce e mantiene. Non si costruisce l’integrazione da zero. Si configurano i pacchetti, si adattano i mapping al proprio modello dati, e si gestisce l’ambiente Integration Suite.

La risposta più lunga — quella che conta per chi deve pianificare un progetto — è quello che trovate in questo articolo.

In sintesi: Sales Cloud V2 e S/4HANA Public Cloud si connettono tramite iFlow standard SAP su Integration Suite (BTP). I flussi principali coprono replica Business Partner, catalogo prodotti, condizioni di prezzo, trasferimento ordini e stato fattura. La logica personalizzata vive su BTP come estensione side-by-side — mai dentro i sistemi core. Le aziende con cui lavoriamo raggiungono il go-live in una mediana di 14 settimane.

Per una panoramica completa dello stack, leggete la nostra guida allo stack integrato. Qui ci concentriamo sull’architettura di integrazione: cosa muove i dati, come, e dove mettere la logica personalizzata.

Come si connette Sales Cloud V2 a S/4HANA Public Cloud?

Il canale di integrazione è SAP Integration Suite, il servizio di integrazione cloud su SAP BTP. Specificamente, il componente che esegue gli iFlow è Cloud Integration (ex SAP Cloud Integration / CPI). Entrambi i sistemi — Sales Cloud V2 e S/4HANA Public Cloud — espongono API OData proprie. Integration Suite si trova nel mezzo: orchestra il routing dei messaggi, gestisce la trasformazione dei dati e garantisce la consegna affidabile.

La piattaforma non è opzionale. Chiamate API dirette punto-a-punto tra Sales Cloud V2 e S/4HANA sono tecnicamente possibili, ma in produzione creano problemi: nessun monitoraggio centralizzato degli errori, nessuna logica di retry, niente di auditabile. Con Integration Suite, tutto passa attraverso un unico punto di osservazione. Chi opera il sistema dopo il go-live — che sia il team IT del cliente o Spadoom in modalità supporto — ha un runbook chiaro.

L’architettura di rete è semplice: entrambi i sistemi sono cloud, quindi non c’è connettività on-premise da configurare. BTP si connette a S/4HANA Public Cloud tramite endpoint SAP-managed, e a Sales Cloud V2 tramite le sue API REST. Il provisioning iniziale richiede la configurazione dei Communication Systems in S/4HANA e del Destination Service su BTP.

I contenuti di integrazione standard

SAP pubblica pacchetti di integrazione preconfigurati su SAP Business Accelerator Hub (ex API Business Hub). Per lo scenario Sales Cloud V2 con S/4HANA Public Cloud esistono pacchetti specifici che coprono i flussi principali.

Non si tratta di template generici da riscrivere. Sono iFlow funzionanti, documentati, e aggiornati da SAP con ogni release. Il lavoro di implementazione consiste nel configurarli — parametri di connessione, mapping dei campi, regole di filtro — non nel costruirli da zero.

Cosa coprono i pacchetti standard:

• Replica Business Partner — da S/4HANA verso Sales Cloud V2. Clienti, fornitori, referenti. Event-driven: quando un BP cambia in S/4HANA, l’iFlow lo propaga.
• Sincronizzazione catalogo prodotti — materiali da S/4HANA verso il catalogo prodotti di Sales Cloud V2.
• Condizioni di prezzo — listini e condizioni da S/4HANA verso Sales Cloud V2, usati durante la creazione di offerte.
• Trasferimento ordine di vendita — da un’offerta confermata in Sales Cloud V2 verso un ordine di vendita in S/4HANA.
• Stato fattura e pagamento — da S/4HANA verso Sales Cloud V2, così i commerciali vedono lo stato finanziario del cliente direttamente nel CRM.

Questo copre la grande maggioranza di ciò che serve per uno stack commerciale integrato. Le personalizzazioni necessarie di solito riguardano i mapping — field extension, logiche di filtro specifiche — non l’architettura di base.

Replica dei dati anagrafici

La replica del Business Partner è il flusso più critico e, in genere, il primo che si implementa. Senza dati anagrafici corretti in Sales Cloud V2, tutto il resto — offerte, attività, opportunità — diventa inaffidabile.

Il flusso funziona in modalità event-driven: quando un Business Partner viene creato o modificato in S/4HANA, viene generato un evento. L’iFlow su Integration Suite lo riceve, trasforma la struttura dati nel formato atteso da Sales Cloud V2 (che espone API OData V4), e chiama l’API di Sales Cloud per creare o aggiornare il record.

Attenzione al modello dati. S/4HANA usa il concetto unificato di Business Partner (BP) per clienti, fornitori e referenti. Sales Cloud V2 ha entità distinte: Account, Contact, Individual Customer. Il mapping non è uno-a-uno. Ogni progetto richiede una sessione di analisi dei dati prima di configurare l’iFlow. Chi salta questa fase incontra duplicati e dati mancanti in produzione.

Lo stesso principio vale per la sincronizzazione prodotti. I materiali in S/4HANA hanno strutture e classificazioni che raramente corrispondono esattamente al catalogo di Sales Cloud V2. Pianificate tempo per l’analisi e il mapping — di solito una o due settimane, a seconda della complessità del catalogo.

Nelle oltre 12 implementazioni di stack integrati Sales Cloud V2 che abbiamo completato, la fase di analisi e pulizia dei dati anagrafici rappresenta in media il 20–25% del tempo totale di progetto. È il segmento più sottostimato nei piani di progetto dei clienti.

Flussi transazionali

Una volta che i dati anagrafici replicano correttamente, si attivano i flussi transazionali. Questi sono più semplici dal punto di vista del mapping — la struttura dei dati è più standardizzata — ma richiedono attenzione alla gestione degli errori.

Da offerta a ordine. Quando un commerciale converte un’offerta in Sales Cloud V2 in un ordine confermato, l’iFlow crea un ordine di vendita in S/4HANA. Il flusso è quasi sincrono: Sales Cloud chiama Integration Suite, che chiama S/4HANA, che risponde con il numero dell’ordine. Quel numero torna in Sales Cloud V2 e viene salvato sull’opportunità o offerta. Il commerciale vede subito la conferma.

Stato fattura verso Sales Cloud. S/4HANA genera le fatture e gestisce i pagamenti. Queste informazioni arrivano in Sales Cloud V2 tramite un flusso asincrono: S/4HANA pubblica un evento, Integration Suite lo elabora, e Sales Cloud V2 aggiorna lo stato finanziario del cliente. I commerciali non devono entrare in S/4HANA per verificare se un cliente ha fatture aperte prima di una chiamata — vedono tutto nel CRM.

Condizioni di prezzo. Questo flusso è spesso sottovalutato. Se i listini vivono in S/4HANA, devono essere disponibili in Sales Cloud V2 durante la creazione di offerte. La sincronizzazione delle condizioni può essere batch (aggiornamento notturno) o event-driven, a seconda della frequenza con cui i prezzi cambiano. Per la maggior parte delle aziende DACH con cui lavoriamo, un aggiornamento giornaliero è sufficiente.

La verifica live della disponibilità a magazzino durante la creazione di offerte è tecnicamente possibile tramite chiamate OData dirette da Sales Cloud V2 verso S/4HANA, ma aggiunge latenza e dipendenza sincrona. La maggior parte dei progetti non ne ha bisogno: basta comunicare ai clienti i tempi di consegna standard. Se serve, pianificatela esplicitamente — non è inclusa nei pacchetti standard.

Dove vive la logica personalizzata: BTP side-by-side

I due sistemi core — Sales Cloud V2 e S/4HANA Public Cloud — rimangono standard. La logica personalizzata non entra in nessuno dei due. Questo è il principio Clean Core: tutto ciò che è custom vive come estensione side-by-side su BTP.

In pratica, questo significa applicazioni SAP CAP (Cloud Application Programming Model) su Cloud Foundry. Un’estensione CAP può ascoltare eventi da entrambi i sistemi, applicare logica di business, chiamare API di terze parti, e aggiornare Sales Cloud V2 o S/4HANA tramite le loro API OData. Il core rimane intatto. Gli aggiornamenti SAP non toccano le vostre estensioni.

Integration Suite, Event Mesh, Build

SAP Integration Suite è il cuore dell’integrazione. Cloud Integration gestisce gli iFlow standard. API Management espone API personalizzate in modo sicuro. Open Connectors permette di collegare sistemi non-SAP quando necessario.

SAP Event Mesh è la struttura per i pattern event-driven. Quando non volete dipendenze sincrone tra i sistemi — e di solito non le volete — Event Mesh fa da broker: S/4HANA pubblica un evento, Event Mesh lo riceve, l’iFlow o l’estensione CAP lo consuma quando è pronta. Questo disaccoppia i sistemi e rende l’architettura più robusta in caso di brevi interruzioni.

SAP Build — specificamente Build Process Automation — serve per orchestrare passi di approvazione che coinvolgono persone. Un esempio reale: un ordine sopra una certa soglia richiede l’approvazione del direttore commerciale prima di passare in S/4HANA. Build gestisce il flusso di approvazione, notifica via email, e rilascia l’ordine quando l’approvazione arriva. Niente codice custom, niente webhook da costruire — è un caso d’uso nato per Build.

Nei progetti che abbinano Sales Cloud V2 a S/4HANA Public Cloud, la combinazione Integration Suite + Event Mesh per i flussi dati e CAP per le estensioni funzionali è la configurazione che regge meglio nel tempo. I clienti che hanno tentato di mettere logica custom dentro gli iFlow standard si sono trovati con problemi a ogni aggiornamento SAP. La separazione delle responsabilità — iFlow standard per il trasporto, CAP per la logica — è la scelta giusta.

Problemi comuni e come evitarli

“SAP integrato significa pronto fuori dalla scatola.” Falso. I pacchetti di integrazione standard sono un punto di partenza solido, non un prodotto finito. Richiedono configurazione, mapping e test. Chi si aspetta di attivare il pacchetto e avere tutto funzionante in un giorno si trova con sorprese. Pianificate 4–6 settimane per configurazione, test e adeguamento dei mapping, anche con i contenuti standard.

Modificare gli iFlow standard direttamente. Errore classico. SAP aggiorna i pacchetti di integrazione. Se avete modificato l’iFlow originale, non potete applicare l’aggiornamento SAP senza sovrascrivere le vostre modifiche — o senza mergiarle a mano. Il metodo corretto: copiate l’iFlow standard in un proprio spazio di lavoro, fate le modifiche sulla copia, documentate il delta rispetto allo standard. Così potete confrontare la vostra versione con quella aggiornata di SAP e applicare le patch necessarie in modo controllato.

Saltare il monitoraggio degli errori. Integration Suite include un monitor degli errori integrato. Molti team lo configurano al minimo durante il progetto e rimandano il monitoraggio “al dopo”. In produzione, un iFlow che fallisce silenziosamente — senza alert — può significare settimane di dati non sincronizzati prima che qualcuno se ne accorga. Configurate alert, definite SLA di retry, assegnate un responsabile per il monitoraggio. Fatelo prima del go-live, non dopo.

Sottostimare qualità e mapping dei dati. È il problema più comune. I dati in S/4HANA — Business Partner, materiali, condizioni — raramente sono pronti per essere sincronizzati senza pulizia. Duplicati, formati inconsistenti, campi vuoti che in Sales Cloud V2 sono obbligatori. Prima di configurare un singolo iFlow, fate un’analisi della qualità dei dati. Definite le regole di mapping in un documento condiviso tra team IT e business. Ogni campo non mappato che scoprite in produzione ha un costo.

Le aziende con cui lavoriamo in ambito DACH arrivano al go-live su questo stack in una mediana di 14 settimane, con un tasso di adozione del 92% a sei mesi. Abbiamo completato oltre 12 implementazioni di questo tipo, alcune partendo da SAP C4C (Sales Cloud V1), altre come nuove implementazioni su stack S/4HANA Public Cloud già esistente.

Per chi sta valutando anche l’integrazione del lato service, lo stesso approccio si applica — leggete il nostro articolo su SAP Service Cloud V2 e S/4HANA.

Avete una domanda specifica sull’architettura di integrazione Sales Cloud V2 + S/4HANA? Oppure state pianificando un progetto e volete un secondo parere sul design? Scriveteci — niente pitch, solo una conversazione tecnica.