Side-by-side: estendere S/4HANA Public Cloud con piccole app Cloud Foundry, senza sacrificare il clean core

Ogni progetto S/4HANA Public Cloud arriva al momento in cui l’estensibilità key-user tocca il suo tetto. Un campo aggiuntivo, una validazione, un layout dell’app adattato: nessun problema, è fatta per questo. Ma poi le vendite vogliono una dashboard che aggreghi il fatturato su più anni e decine di migliaia di documenti. Oppure un reparto ha bisogno di un piccolo processo che lo standard semplicemente non conosce. E all’improvviso la domanda è sul tavolo: dobbiamo comunque toccare il nucleo?

No. La risposta si chiama side-by-side: una piccola applicazione su SAP BTP Cloud Foundry che vive accanto al sistema e gli parla esclusivamente tramite API released. L’ERP resta intatto, l’estensione gira a fianco. E piccola va intesa in senso letterale.

Il modello: una piccola app accanto al sistema

Il progetto costruttivo è sempre lo stesso, ed è esattamente questa la sua forza. Nel backend un servizio CAP (Cloud Application Programming Model, Node.js o Java) che recupera, aggrega o arricchisce i dati da S/4HANA. Davanti, un frontend: Fiori/UI5 se l’app deve sembrare SAP, oppure un frontend web leggero se non serve. La connessione verso l’ERP passa dal servizio Destination e dagli accordi di comunicazione in S/4HANA, e si consumano solo API released dal SAP Business Accelerator Hub.

Tutto qui. Nessuno zoo di framework, nessuna piattaforma fatta in casa, nessuna modifica. Chi ha già messo in piedi un progetto Node.js si orienta in CAP nel giro di giorni. E poiché Cloud Foundry fattura la memoria per istanza, un’app che gira in poche centinaia di MB costa quasi nulla da esercire.

Un esempio da uno dei nostri progetti

Presso un’azienda commerciale svizzera, le vendite volevano vedere nel CRM cosa un cliente avesse davvero comprato negli anni: fatturato per anno, per gruppo di prodotti, tendenza. I dati grezzi vivono nell’ERP, distribuiti su circa 75’000 ordini cliente. Nessun report CRM standard copre questo, e nessuno voleva mettere mano all’ERP per farlo.

Così abbiamo costruito una piccola app side-by-side: un servizio CAP che legge gli ordini tramite l’API released degli ordini cliente, li aggrega per cliente e serve una dashboard leggera. Il tutto è integrato come mashup direttamente in SAP Sales Cloud V2, con SSO via iframe perché nessuno debba autenticarsi due volte. Il venditore apre il cliente nel CRM e vede la dashboard come se fosse parte del prodotto.

Il bilancio: l’ERP non è mai stato toccato. L’app gira in poche centinaia di MB di memoria Cloud Foundry. I costi mensili di infrastruttura stanno nell’ordine delle due cifre in franchi. E le vendite hanno ottenuto una vista sul cliente che prima semplicemente non esisteva.

La checklist di architettura

Perché il modello resti pulito, in ogni progetto ci atteniamo a cinque punti:

1. Solo API released. Ciò che non è documentato come released nel SAP Business Accelerator Hub non viene consumato. Punto. Questa sola regola decide se l’app sopravvive agli upgrade.
2. Un accordo di comunicazione per scenario. Non un accordo unico con tutti gli scope, ma un accordo dedicato per ogni caso d’uso di business. Questo mantiene le autorizzazioni tracciabili e le dismissioni indolori.
3. Principal propagation o utente tecnico: decidere consapevolmente. Se l’ERP deve sapere quale persona sta interrogando, serve la principal propagation. Se basta un utente tecnico, è più semplice, ma allora è l’app stessa a verificare chi può vedere cosa. Entrambe le vie sono legittime; l’indecisione no.
4. Servizio Destination invece di URL nel codice. Endpoint, credenziali e metodo di autenticazione vivono nella destination, mai nel repository.
5. Un subaccount BTP per stage. Test e produzione separati, ogni stage con le proprie destination verso il tenant S/4HANA corrispondente. Sembra ovvio, e de facto viene saltato sorprendentemente spesso.

La ricompensa: upgrade di cui nessuno si cura

Qui la disciplina ripaga. S/4HANA Public Cloud riceve i suoi upgrade di release a cadenza trimestrale, che lo si voglia o no. Chi avesse modificato il nucleo, ora testerebbe le proprie modifiche ogni trimestre. L’app side-by-side, invece, dell’upgrade non si accorge affatto, perché usa solo API released e versionate di cui SAP garantisce la compatibilità. La nostra dashboard dell’esempio ha attraversato diversi cambi di release. Sforzo da parte nostra: zero.

Questo è il vero senso del clean core. Non un dogma, ma la libertà di lasciare che gli upgrade semplicemente accadano.

Know-how di progetto: costruire noioso

La regola più importante per le app side-by-side è poco spettacolare: costruitele noiose. Dashboard orientate alla lettura, piccoli scenari di scrittura tramite API released, compiti chiaramente delimitati. È esattamente lì che il modello mostra la sua forza.

Due campanelli d’allarme da progetti che abbiamo rilevato. Primo: se vi sorprendete a replicare metà dell’ERP in una HANA Cloud, fermatevi e rimettete in discussione l’obiettivo. Da quel punto in poi non state più costruendo uno scenario di estensione, ma un secondo sistema con tutti i problemi di sincronizzazione che ne derivano. Secondo: tenete d’occhio i limiti di frequenza delle API. Le API released sono limitate, e un’app che a ogni caricamento di pagina interroga di nuovo 75’000 documenti lo impara nel modo doloroso. Aggregare, mettere in cache, ricaricare a orari pianificati: senza gloria, ma esattamente giusto.

Domande frequenti

Quanto costa l’esercizio di una piccola app Cloud Foundry?

Meno di quanto la maggior parte si aspetti. Si paga essenzialmente la memoria Cloud Foundry (ore-GB) più piccole voci per i servizi Destination e Authorization. Un’app con poche centinaia di MB di memoria finisce a due cifre in franchi al mese. Il blocco di costi rilevante non è l’esercizio, è la costruzione, e anche quella resta contenuta per uno scenario mirato.

Quando l’estensibilità key-user, quando BTP Cloud Foundry, quando Steampunk?

La nostra regola pratica: estensibilità key-user per campi, validazioni e adattamenti dell’interfaccia dentro un’app esistente. BTP Cloud Foundry non appena servono un’aggregazione dati propria, un’interfaccia propria o l’integrazione in un altro sistema (un CRM, per esempio). Steampunk, cioè ABAP Cloud embedded o su BTP, quando la logica deve vivere vicino alle transazioni ERP e il team porta competenze ABAP. Ad ABAP Cloud dedicheremo presto un articolo a parte, tra l’altro.

Un’app del genere può essere integrata in SAP Sales Cloud V2?

Sì, ed è uno dei casi d’uso più belli. Sales Cloud V2 integra l’app come mashup, via iframe direttamente nella vista cliente o opportunità. Con un SSO impostato a dovere, gli utenti non si accorgono di lavorare in un’app esterna. È esattamente così che gira la nostra dashboard del fatturato dell’esempio.

L’app si rompe quando SAP cambia l’API?

Le API released sono versionate, e SAP mantiene stabili le versioni esistenti. Le nuove versioni arrivano in modo additivo. Il rischio sta quasi interamente nelle interfacce non released, ed è precisamente per questo che la regola numero uno della checklist sta dove sta.

La vostra estensibilità key-user è al limite e la prossima proposta sul tavolo si chiama modifica del nucleo? Vi mostriamo volentieri come appare il modello side-by-side nel vostro caso. Parlate con noi.