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à per key user tocca il suo limite. Un campo in più, una validazione, un layout adattato: nessun problema, è fatta per questo. Ma poi le vendite vogliono una dashboard che aggreghi i ricavi su più anni e decine di migliaia di documenti. Oppure un reparto ha bisogno di un piccolo processo che lo standard non conosce. E la domanda arriva sul tavolo: dobbiamo toccare il nucleo, dopo tutto?

No. La risposta è side-by-side: una piccola applicazione su SAP BTP Cloud Foundry che vive accanto al sistema e parla con esso esclusivamente tramite API rilasciate. L’ERP resta intatto, l’estensione gira accanto, e piccola va inteso alla lettera.

In sintesi: Quando l’estensibilità per key user non basta, si costruisce una piccola applicazione CAP su SAP BTP Cloud Foundry che legge e scrive in S/4HANA Public Cloud solo tramite API rilasciate, collegata tramite il servizio Destination e un communication arrangement dedicato. La si tiene noiosa: dashboard prevalentemente in lettura e piccoli scenari di scrittura ben delimitati. Gli aggiornamenti passano allora senza che nessuno se ne accorga, e i costi di esercizio restano bassi.

Il modello: una piccola app accanto al sistema

Lo schema è sempre lo stesso, ed è proprio questa la sua forza. Nel backend, un servizio costruito con il SAP Cloud Application Programming Model (CAP), in Node.js o Java, che legge, aggrega o arricchisce dati da S/4HANA. Davanti, un frontend: SAPUI5/Fiori se l’app deve sembrare SAP, un semplice frontend web se non è necessario. Il collegamento all’ERP passa dal servizio Destination e da un communication arrangement in S/4HANA, e si usano solo API rilasciate del SAP Business Accelerator Hub. SAP documenta l’approccio come estensibilità side-by-side con SAP BTP.

Tutto qui. Nessuno zoo di framework, nessuna piattaforma propria, nessuna modifica. Chi ha già impostato un progetto Node.js si orienta in CAP in pochi giorni. E poiché l’ambiente Cloud Foundry fattura la memoria per istanza, un’app che gira in qualche centinaio di MB costa poco da gestire.

Un esempio da uno dei nostri progetti

In un’azienda commerciale svizzera, le vendite volevano vedere nel CRM che cosa un cliente avesse acquistato negli anni: ricavi per anno, per gruppo di prodotti, tendenza. I dati grezzi vivono nell’ERP, distribuiti su circa 75’000 ordini di vendita. Nessun report standard del CRM li copre, e nessuno voleva modificare l’ERP per questo.

Abbiamo quindi costruito una piccola app side-by-side: un servizio CAP che legge gli ordini tramite l’API rilasciata degli ordini di vendita, li aggrega per cliente e serve una dashboard snella. È integrata come mashup direttamente in SAP Sales Cloud V2, con single sign-on, così nessuno accede due volte. Il commerciale apre il cliente nel CRM e vede la dashboard come se facesse parte del prodotto.

Il risultato: l’ERP non è mai stato toccato. L’app gira in qualche centinaio di MB di memoria Cloud Foundry e i costi mensili di infrastruttura restano nell’ordine delle decine di franchi. Le vendite hanno ottenuto una visione del cliente che prima non esisteva. Lo stesso modello sul lato CRM è descritto nel nostro articolo su come estendere Sales Cloud V2 con app Cloud Foundry personalizzate.

La checklist di architettura

Per tenere pulito il modello, in ogni progetto ci atteniamo a cinque punti:

1. Solo API rilasciate. Se non è documentata come rilasciata sul SAP Business Accelerator Hub, non si usa. Questa sola regola decide se l’app sopravvive agli aggiornamenti.
2. Un communication arrangement per scenario. Non un arrangement tuttofare con ogni ambito, ma uno dedicato per ciascun caso d’uso. Così le autorizzazioni restano tracciabili e la dismissione indolore.
3. Principal propagation o utente tecnico: decidere consapevolmente. Se l’ERP deve sapere quale persona sta chiedendo, serve la principal propagation. Un utente tecnico è più semplice, ma allora è l’app stessa a controllare chi può vedere che cosa. Entrambe le scelte sono legittime; l’indecisione no.
4. Servizio Destination invece di URL nel codice. Endpoint, credenziali e metodo di autenticazione stanno nella destination, mai nel repository.
5. Un sottoaccount BTP per ambiente. Test e produzione separati, ciascuno con destination che puntano al sistema S/4HANA corrispondente. Sembra ovvio e viene saltato sorprendentemente spesso.

Il vantaggio: aggiornamenti di cui nessuno deve preoccuparsi

S/4HANA Public Cloud riceve i suoi aggiornamenti di release secondo il calendario di SAP, che piaccia o no. Chi avesse modificato il nucleo testerebbe le proprie modifiche a ogni aggiornamento. L’app side-by-side non si accorge dell’aggiornamento, perché usa solo API rilasciate e versionate che SAP mantiene stabili. La nostra dashboard dell’esempio ha attraversato diverse release senza alcun lavoro da parte nostra.

È questo il senso del clean core: non un dogma, ma la libertà di lasciare che gli aggiornamenti avvengano.

Costruire in modo noioso

La regola più importante per le app side-by-side non ha nulla di spettacolare: costruirle noiose. Dashboard prevalentemente in lettura, piccoli scenari di scrittura tramite API rilasciate, compiti chiaramente delimitati. È lì che il modello rende al meglio.

Due segnali d’allarme da progetti che abbiamo rilevato. Primo: se si sta replicando mezzo ERP in un database HANA Cloud, conviene fermarsi e ripensare il quadro obiettivo. Da quel momento si sta costruendo un secondo sistema, con tutti i problemi di sincronizzazione che comporta. Secondo: attenzione ai limiti di chiamata delle API. Un’app che interroga di nuovo 75’000 documenti a ogni caricamento di pagina impara a proprie spese che le API rilasciate sono limitate. Aggregare, mettere in cache e ricaricare a intervalli.

Se invece la logica deve stare in modo sincrono nel flusso documentale dell’ERP, lo strumento migliore è ABAP Cloud; lo abbiamo descritto in Embedded Steampunk in S/4HANA Public Cloud. Sta scegliendo un partner per questo tipo di lavoro? La nostra panoramica dei partner di sviluppo SAP BTP in Svizzera indica che cosa chiedere, e SAP BTP da Spadoom mostra come lavoriamo. Le app side-by-side sono anche un elemento tipico dello stack integrato S/4HANA Public Cloud e Sales Cloud V2, ed è per questo che copriamo entrambe le metà con un unico team, come descritto nella nostra guida al miglior partner SAP per Cloud ERP e CRM in Svizzera.

Domande frequenti

Quanto costa gestire una piccola app Cloud Foundry?

Meno di quanto molti pensino. Si paga essenzialmente la memoria Cloud Foundry più piccole voci per servizi come destination e autorizzazioni. La nostra app d’esempio con qualche centinaio di MB di memoria costa poche decine di franchi al mese; il costo rilevante è la realizzazione, non l’esercizio, e anche quello resta contenuto per uno scenario mirato.

Quando l’estensibilità per key user, quando BTP Cloud Foundry, quando ABAP Cloud?

Estensibilità per key user per campi, validazioni e adattamenti dell’interfaccia dentro un’app esistente. BTP Cloud Foundry quando servono un’aggregazione di dati propria, un’interfaccia propria o l’integrazione in un altro sistema, per esempio un CRM. ABAP Cloud (estensibilità per sviluppatori, detta anche Embedded Steampunk) quando la logica deve girare vicino alle transazioni ERP e il team porta competenze ABAP.

Un’app del genere si può integrare in SAP Sales Cloud V2?

Sì. Sales Cloud V2 integra l’app come mashup nella vista dell’account o dell’opportunità. Con il single sign-on configurato bene, gli utenti non si accorgono di lavorare in un’app esterna; è così che gira la dashboard dei ricavi del nostro esempio.

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

Le API rilasciate sono versionate e SAP mantiene stabili le versioni rilasciate; le nuove versioni si aggiungono. Il rischio sta quasi interamente nelle interfacce non rilasciate, ed è per questo che la prima regola della nostra checklist è usare solo API rilasciate.

---

La Sua estensibilità per key user è al limite e la prossima proposta sul tavolo parla di modifica del nucleo? Le mostriamo come appare il modello side-by-side nel Suo caso. Parli con il nostro team.