Generazione RAP Business Object
Anatomia del sample XCO che compone un business object RAP, con dipendenze, confini di attivazione e teardown.
In breve
Sezione intitolata “In breve”Il sample SAP di generazione RAP è interessante non perché prometta un “business object con un pulsante”, ma perché rende visibile la catena completa delle dipendenze. Un’unica intenzione — pubblicare una richiesta di ferie — diventa dominio, data element, tabella, due entità CDS, metadata extension, access control, behavior, classe handler, service definition e service binding. Le XCO Generation APIs descrivono ciascun oggetto con una specifica tipizzata; coerenza dei nomi, trasporto e ordine di esecuzione restano responsabilità del chiamante (RAP BO Generation).
La mappa delle dipendenze
Sezione intitolata “La mappa delle dipendenze”La tabella ricostruisce il sample come piano, separando repository object e ruolo applicativo:
| Strato | Oggetto | Dipende da | Cosa stabilisce |
|---|---|---|---|
| Vocabolario | DOMA | — | Valori fissi dello stato |
| Vocabolario | DTEL | DOMA | Tipo riusabile per lo stato |
| Persistenza | TABL | DTEL e tipi built-in | Campi, chiave e record persistenti |
| Modello | DDLS interface | TABL | Root view entity e filtro dei record attivi |
| Consumo | DDLS projection | DDLS interface | Superficie esposta al servizio |
| UI | DDLX | DDLS interface | Annotazioni UI.lineItem e UI.identification |
| Autorizzazione | DCLS | DDLS interface | Regola di accesso dimostrativa |
| Comportamento | BDEF interface | DDLS interface, TABL, CLAS | Managed behavior, mapping, lock e azione |
| Comportamento | BDEF projection | BDEF interface | Operazioni riusate dal livello di consumo |
| Implementazione | CLAS | BDEF interface | Handler locale dell’azione |
| Servizio | SRVD | DDLS projection | Esposizione con alias |
| Binding | SRVB | SRVD | Binding OData e versione del servizio |
La direzione conta. La projection non legge direttamente la tabella: proietta la view di interfaccia. Il behavior mappa campi CDS e campi persistenti. Il servizio espone la projection, non il repository nel suo complesso. La distinzione XCO tra astrazioni comuni e API specifiche permette di descrivere i pezzi con un vocabolario coerente, ma non corregge automaticamente un riferimento sbagliato.
Due operazioni, non una magia atomica
Sezione intitolata “Due operazioni, non una magia atomica”Nel sample documentato il metodo principale:
- crea un PUT generale;
- aggiunge DOMA, DTEL, TABL, DDLS, DDLX, DCLS, BDEF, CLAS e SRVD;
- esegue quel PUT e la relativa mass activation;
- costruisce ed esegue separatamente il PUT del service binding.
Non è una transazione atomica fino al binding: ogni execute delle Generation APIs comporta COMMIT WORK. Se il secondo passaggio fallisce, il primo può essere già persistito; l’automatore deve registrare il punto raggiunto.
Un comportamento dimostrato, non completato
Sezione intitolata “Un comportamento dimostrato, non completato”La behavior definition del sample è managed, collega la tabella persistente, configura il lock master, mappa i campi e aggiunge le operazioni standard. Dichiara inoltre un’azione approve con risultato sulla stessa entità. La classe generata prepara il metodo handler corrispondente.
Il punto da non perdere è ciò che il sample non dimostra: il corpo del metodo APPROVE viene aggiunto, ma non contiene la logica applicativa che cambia lo stato. La presenza di action, classe e binding prova che XCO sa generare la struttura repository; non prova che il caso d’uso sia funzionalmente completo.
| Il sample prova | Il sample non prova |
|---|---|
| Composizione tipizzata di più object type | Correttezza della regola di approvazione |
| Riferimenti tra tabella, CDS, behavior e servizio | Idempotenza di una pipeline eseguita più volte |
| Attivazione comune degli oggetti raccolti nel PUT | Rollback globale dopo un fallimento del binding |
| Creazione di annotazioni UI e di una DCLS | Adeguatezza produttiva di UI e autorizzazioni |
| Possibilità di generare e cancellare gli oggetti | Compatibilità con ogni release ABAP Cloud |
Questa distinzione evita il falso positivo più comune: un binding attivo non equivale a un business object pronto per la produzione.
Il teardown è il grafo al contrario
Sezione intitolata “Il teardown è il grafo al contrario”La documentazione cancella prima gli oggetti più esterni e poi le fondamenta:
SRVB → SRVD → CLAS → BDEF → DCLS → DDLX → DDLS projection/interface → TABL → DTEL → DOMAOgni DELETE riguarda uno specifico tipo; l’ordine tra tipi resta al chiamante. Anche qui ogni operazione introduce un commit: un teardown interrotto lascia un grafo parzialmente rimosso da leggere prima di riprovare.
La lezione del sample
Sezione intitolata “La lezione del sample”Il sample RAP è una lezione sui confini di responsabilità. XCO struttura la generazione; RAP separa persistenza, modello, behavior e servizio; l’orchestratore conserva dipendenze e stato parziale. Automatizzare bene significa rendere osservabili questi confini.
Il codice sorgente della dimostrazione contiene nomi e trasporti esemplificativi e va adattato. API rilasciate, tipi supportati, semantica RAP e binding disponibili possono cambiare tra release e modalità di estensibilità. La demo di riferimento non è un template produttivo: servono autorizzazioni reali, implementazione del behavior, gestione degli errori, test funzionali e verifica nel sistema target. Non estrapolare automaticamente il flusso verso sistemi ABAP o release differenti.