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

Pochi linguaggi sono stati sepolti tante volte quanto ABAP. E pochi continuano a vivere con altrettanta costanza. In SAP S/4HANA Public Cloud è tornato, ma non come l’ABAP degli user exit e dei programmi 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 il Public Cloud abbia da offrire. Nei nostri progetti la partenza fallisce raramente sulla tecnica. Fallisce sulla terminologia.

Prima mettere in ordine i termini

Intorno a S/4HANA Public Cloud esistono tre livelli di estensibilità, e nei workshop vengono confusi con notevole regolarità:

L’estensibilità key user è il gradino più basso: campi personalizzati, piccoli frammenti di logica, schermate adattate, tutto direttamente nell’interfaccia Fiori e senza ambiente di sviluppo. Un power user di reparto capace arriva sorprendentemente lontano qui, senza alcuno sviluppatore.

L’estensibilità developer, alias Embedded Steampunk, è vero ABAP nel tenant di sviluppo del sistema S/4HANA Public Cloud stesso. Stesso stack, stesso database, editor completo. Ma sotto il regolamento di ABAP Cloud, ci arriviamo subito.

Lo Steampunk side-by-side è il BTP ABAP Environment: una piattaforma ABAP autonoma su SAP BTP, con il proprio database HANA, separata dall’ERP. La comunicazione passa esclusivamente attraverso API.

Chi preferisce costruire side-by-side senza ABAP ha a disposizione anche Cloud Foundry sulla BTP; come si presenta lo abbiamo descritto in un articolo dedicato.

Cosa significa ABAP Cloud in concreto

ABAP Cloud non è un nuovo ABAP, è un sottoinsieme con un recinto rigido. Quattro cose da interiorizzare prima della prima riga di codice:

• Solo oggetti e API rilasciati sono raggiungibili. Nessuna SELECT diretta su tabelle non rilasciate, nessun user exit, nessuna modifica del codice SAP. Ciò che SAP non ha marcato come released, per il vostro codice semplicemente non esiste.
• RAP è il modello di programmazione. L’ABAP RESTful Application Programming Model struttura tutto: viste CDS come modello dati, behavior definition per la logica, service binding verso il mondo esterno. Chi padroneggia RAP, padroneggia Embedded Steampunk.
• Si sviluppa in Eclipse. Gli ABAP Development Tools (ADT) sono l’unico IDE. Nel Public Cloud non esiste una SE80, e nessuno ne sente la mancanza a lungo.
• Il trasporto passa da software component basati su gCTS, attraverso i tre sistemi DEV → TEST → PROD. Versionamento Git incluso, un vero passo avanti rispetto a qualsiasi regime di trasporto classico.

La scala decisionale dai nostri progetti

Per decidere su quale livello atterra 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. Una quantità sorprendente di esigenze ci sta dentro: campi aggiuntivi sui documenti, controlli sui 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 business object rilasciati, app Fiori personalizzate su propri oggetti RAP, logica che siede in modo sincrono nel flusso documentale. È esattamente per questo che è stato costruito.
3. Side-by-side sulla BTP quando è un prodotto a sé. Applicazioni con il proprio ciclo di vita, il proprio ritmo di release, o scenari che aggregano dati da più sistemi. Quello sta accanto all’ERP, non dentro.

La scala suona banale. Eppure fa risparmiare settimane in ogni progetto, perché sposta la discussione da «cosa sarebbe bello» a «cosa è necessario».

Tre cose che portiamo in ogni progetto

L’albero decisionale clean core, una pagina, settimana uno. Insieme all’IT del cliente disegniamo nella prima settimana di progetto un albero decisionale: quale requisito atterra su quale livello, e secondo quali criteri? Una pagina A4, pronta da plastificare. Quella sola pagina chiude ogni futuro dibattito di architettura prima che nasca. Lo sforzo è mezza giornata; il ritorno è ogni giro di escalation che non avviene mai.

Verificare presto la lista delle API rilasciate. Non sono i desideri a decidere l’architettura, sono le lacune. Se l’oggetto che volete estendere dispone di API, BAdI e viste CDS rilasciate si chiarisce al giorno due, non allo sprint cinque. Abbiamo visto iniziative pianificate per tre settimane come soluzioni Embedded Steampunk, finché qualcuno ha controllato e ha scoperto: l’oggetto target non è rilasciato. Si riparte da capo.

Gli upgrade trimestrali passano da soli. S/4HANA Public Cloud applica gli upgrade di release automaticamente. Il codice ABAP Cloud su API rilasciate li attraversa senza che nessuno lo tocchi; le API rilasciate sono contratti, e SAP le mantiene stabili. È tutto il senso dell’esercizio. Chi lo ha vissuto una volta, dopo anni di progetti di upgrade con liste SPAU, capisce improvvisamente il recinto intorno ad ABAP Cloud come una funzionalità.

I limiti onesti

Non esistono modifiche agli oggetti SAP. Punto, nessuna eccezione, nessun trucco. E non tutto ciò che si conosce da ECC è rilasciato: alcune BAPI e alcuni moduli funzione classici mancano ancora oggi dalla lista.

Davanti a una lacuna dura c’è una via collaudata: aprire una influence request presso SAP (i cicli di release sono brevi, le probabilità reali, abbiamo visto rilasci arrivare entro due cicli) e costruire nel frattempo un ponte side-by-side sulla BTP, da smontare più avanti. Non un bel momento, ma un momento pianificabile. Diventa brutto solo se la lacuna la scoprite durante i test di integrazione, vedi sopra.

Domande frequenti

ABAP è morto nel Public Cloud?

No, al contrario. ABAP è tornato in S/4HANA Public Cloud come ABAP Cloud: moderno, con RAP come modello di programmazione e un regolamento chiaro. Ciò che è sparito sono le modifiche e i programmi Z selvaggi. Potete chiamarla una perdita. Noi la chiamiamo disciplina, e il bilancio degli upgrade dà ragione a questa lettura.

Gli sviluppatori ABAP di lunga data devono reimparare tutto?

Reimparare sì, tutto no. Il linguaggio resta ABAP, cambia la mentalità: RAP invece dei report, API rilasciate invece dell’accesso diretto, Eclipse invece della SE80. Nella nostra esperienza è un ramp-up mirato di settimane, non di mesi, a condizione che una persona con pratica RAP accompagni i primi oggetti.

Dove vive il codice, esattamente?

Nel tenant di sviluppo della propria istanza S/4HANA Public Cloud, organizzato in software component. Da lì viaggia su base gCTS, versionato, attraverso DEV → TEST → PROD. Nessun sistema separato, nessuna infrastruttura propria, ma una separazione pulita dallo standard SAP.

State pianificando estensioni in S/4HANA Public Cloud e volete rispondere alla domanda di architettura prima che diventi costosa? L’albero decisionale lo portiamo noi. Parlate con noi.