ABAP è vivo: usare bene Embedded Steampunk in S/4HANA Public Cloud

Pochi linguaggi di programmazione sono stati dichiarati morti tante volte quanto ABAP, e pochi continuano a vivere con tanta regolarità. In SAP S/4HANA Public Cloud è tornato, anche se non come l’ABAP di user exit e report Z che si conosce da vent’anni di ECC. Il regolamento si chiama ABAP Cloud, il soprannome è Embedded Steampunk, e usato bene è lo strumento di estensione più preciso che la Public Cloud offra. Nei nostri progetti l’avvio raramente fallisce sulla tecnologia. Fallisce sulla terminologia.

In sintesi: S/4HANA Public Cloud ha tre livelli di estensibilità: l’estensibilità per key user nell’interfaccia Fiori, l’estensibilità per sviluppatori con ABAP Cloud dentro il sistema (Embedded Steampunk) e le estensioni side-by-side su SAP BTP. ABAP Cloud significa solo API rilasciate, RAP come modello di programmazione e gli ABAP Development Tools in Eclipse. Si parte dal livello più basso che risolve il requisito e si verifica presto se l’oggetto da estendere è rilasciato.

Prima si chiariscono i termini

Esistono tre livelli di estensibilità in S/4HANA Public Cloud e attorno a esso, e nei workshop vengono confusi con notevole regolarità:

L’estensibilità per key user è il gradino più basso: campi personalizzati, piccoli frammenti di logica e schermate adattate, direttamente nell’interfaccia Fiori e senza ambiente di sviluppo. Un utente esperto del business arriva sorprendentemente lontano.

L’estensibilità per sviluppatori, detta anche Embedded Steampunk, è vero ABAP dentro S/4HANA Public Cloud stesso, nel sistema di sviluppo del panorama a tre sistemi. Stesso stack, stesso database, editor completo, ma con il regolamento ABAP Cloud. SAP la descrive nella guida sull’estensibilità per sviluppatori in S/4HANA Cloud Public Edition.

Lo Steampunk side-by-side è l’ambiente ABAP di SAP BTP: una piattaforma ABAP separata su SAP BTP con un proprio database, disaccoppiata dall’ERP. La comunicazione passa solo tramite API.

Se si preferisce costruire side-by-side senza ABAP, anche l’ambiente Cloud Foundry su BTP è a disposizione; abbiamo descritto come si presenta in un articolo dedicato.

Che cosa significa ABAP Cloud in pratica

ABAP Cloud non è un nuovo ABAP ma un sottoinsieme governato, con una recinzione rigida. Quattro cose da interiorizzare prima della prima riga di codice:

• Sono raggiungibili solo oggetti e API rilasciati. Nessuna SELECT diretta su tabelle non rilasciate, nessuna user exit, nessuna modifica del codice SAP. Ciò che SAP non ha marcato come rilasciato, per il Suo codice non esiste.
• RAP è il modello di programmazione. L’ABAP RESTful Application Programming Model struttura tutto: viste CDS come modello di dati, behaviour definition per la logica, service binding verso l’esterno. Chi conosce RAP conosce Embedded Steampunk.
• Lo sviluppo avviene in Eclipse. Gli ABAP Development Tools (ADT) sono l’ambiente di sviluppo. Nella Public Cloud non c’è la SE80, e nessuno ne sente a lungo la mancanza.
• I trasporti passano per componenti software attraverso il panorama a tre sistemi: gli sviluppatori li rilasciano da ADT e vengono importati in test e produzione con l’app Import Collection.

La scala decisionale dai nostri progetti

Per decidere a quale livello appartiene un requisito, si è dimostrata utile una scala semplice. Si parte dal basso e si sale solo quando non c’è altra strada:

1. Prima il key user. Ci sta sorprendentemente molto: campi aggiuntivi sui documenti, controlli dei campi, piccole validazioni, layout adattati. Chi salta questo gradino costruisce soluzioni da sviluppatore per problemi di configurazione e le paga due volte.
2. Embedded Steampunk quando la logica deve girare nello stack. Determinazioni e validazioni su oggetti di business rilasciati, app Fiori personalizzate su oggetti RAP propri, logica che si inserisce in modo sincrono nel flusso documentale. È esattamente ciò per cui è costruito.
3. BTP side-by-side quando si tratta di un prodotto a sé. Applicazioni con un proprio ciclo di vita e ritmo di rilascio, o scenari che aggregano dati da più sistemi. Stanno accanto all’ERP, non dentro; si veda SAP BTP da Spadoom.

La scala sembra banale. Fa comunque risparmiare settimane in ogni progetto, perché sposta la discussione da «che cosa sarebbe bello» a «che cosa è necessario».

Tre cose che portiamo in ogni progetto

L’albero decisionale del clean core, una pagina, prima settimana. Insieme all’IT del cliente disegniamo nella prima settimana di progetto un albero decisionale: quale requisito va a quale livello, e secondo quali criteri. Una pagina A4 chiude in anticipo la maggior parte dei futuri dibattiti di architettura. Costa mezza giornata.

Verificare presto l’elenco delle API rilasciate. Sono le lacune a decidere l’architettura, non i desideri. Se l’oggetto da estendere dispone di API, BAdI e viste CDS rilasciate lo si chiarisce il secondo giorno, non nel quinto sprint. Abbiamo visto iniziative pianificate per tre settimane come soluzioni Embedded Steampunk finché qualcuno non ha controllato e scoperto che l’oggetto di destinazione non era rilasciato.

Lasciar passare gli aggiornamenti di release. S/4HANA Public Cloud applica gli aggiornamenti di release secondo il calendario di SAP. Il codice ABAP Cloud su API rilasciate li supera senza che nessuno lo tocchi, perché le API rilasciate sono contratti che SAP mantiene stabili. Dopo anni di progetti di aggiornamento con liste SPAU, la recinzione attorno ad ABAP Cloud si legge come una funzionalità.

I limiti

Non ci sono modifiche di oggetti SAP, e non tutto ciò che si conosce da ECC è rilasciato: alcune BAPI e alcuni moduli funzione classici mancano ancora dall’elenco dei rilasciati.

Quando si incontra una lacuna netta, esiste una strada collaudata: presentare a SAP una influence request e costruire nel frattempo un ponte side-by-side su BTP, da smontare quando SAP rilascia ciò che serve. Non è un momento piacevole, ma è pianificabile. Diventa brutto solo quando la lacuna emerge durante i test di integrazione.

Prendere presto queste decisioni fa parte di ciò che copre l’assessment di prontezza S/4HANA. Le estensioni raramente restano dentro l’ERP: le stesse regole clean core valgono per il lato CRM dello stack integrato S/4HANA Public Cloud e Sales Cloud V2, e la nostra guida al clean core con SAP CAP mostra la controparte su BTP. Se sta confrontando partner di implementazione, si vedano i migliori partner SAP S/4HANA Public Cloud in Svizzera e la nostra guida al miglior partner SAP per Cloud ERP e CRM in Svizzera.

Domande frequenti

ABAP è morto in S/4HANA Public Cloud?

No. ABAP fa parte di S/4HANA Public Cloud come ABAP Cloud, con l’ABAP RESTful Application Programming Model (RAP) e un regolamento chiaro: solo API rilasciate, nessuna modifica. Sono scomparse le modifiche e i programmi Z senza vincoli, ed è proprio questo che rende gli aggiornamenti tranquilli.

Gli sviluppatori ABAP esperti devono riqualificarsi completamente?

Riqualificarsi sì, completamente no. Il linguaggio resta ABAP; cambia la mentalità: RAP invece dei report, API rilasciate invece dell’accesso diretto alle tabelle, gli ABAP Development Tools basati su Eclipse invece della SE80. Nella nostra esperienza è un avviamento mirato di qualche settimana, a condizione che qualcuno con pratica di RAP accompagni i primi oggetti.

Dove vive il codice?

Nel sistema di sviluppo del panorama a tre sistemi di S/4HANA Public Cloud, organizzato in componenti software. Gli sviluppatori rilasciano i trasporti dagli ABAP Development Tools, e le estensioni vengono importate prima nel sistema di test e poi in quello di produzione con l’app Import Collection. Non serve alcuna infrastruttura separata.

---

Sta pianificando estensioni in S/4HANA Public Cloud e vuole risolvere la questione di architettura prima che diventi costosa? Portiamo noi l’albero decisionale. Parli con il nostro team.