API di generazione ABAP Cloud
Il contratto operativo delle XCO Generation APIs, dalla specifica tipizzata al trasporto, all’attivazione e al COMMIT WORK.
In breve
Sezione intitolata “In breve”Le XCO Generation APIs creano, aggiornano e cancellano oggetti del repository ABAP tramite specifiche tipizzate. Il chiamante non consegna una porzione di sorgente a un generatore generico: sceglie un tipo di oggetto, lo aggiunge a un’operazione e ne compila la form specification. L’esecuzione lega insieme repository, package, trasporto, attivazione e commit. È questa ampiezza del contratto — non soltanto la sintassi fluente — a rendere l’automazione potente e rischiosa (Generation APIs).
Scegliere l’operazione
Sezione intitolata “Scegliere l’operazione”I quattro verbi non sono sinonimi:
| Operazione | Identità dell’oggetto | Semantica | Esempi di tipi documentati |
|---|---|---|---|
PUT |
Nome esplicito | Crea se assente, aggiorna se presente | BDEF, CLAS, DDLS, DOMA, DTEL, SRVD, TABL |
POST |
Una name choice risolta all’esecuzione | Crea solo dopo che tutti i nomi sono disponibili | FUGR |
PATCH |
Nome esplicito e modifica specifica del tipo | Cambia una parte senza ridefinire necessariamente l’intero oggetto | CLAS, FUGR, INTF, MSAG |
DELETE |
Nome esplicito | Elimina l’oggetto se esiste | Tutti i tipi elencati nella matrice della release di riferimento |
La matrice è parte del contratto di release. Non si può dedurre che un tipo supporti PATCH soltanto perché supporta PUT. Per una message class, inoltre, le modifiche INSERT, UPDATE, MODIFY e DELETE hanno semantiche distinte; la scelta va fatta sul comportamento desiderato, non sul verbo più comodo (Design of the XCO Generation APIs).
Un PUT minimo, con i confini visibili
Sezione intitolata “Un PUT minimo, con i confini visibili”Il seguente frammento riproduce il modello documentato per un data element con nomi dimostrativi. Il trasporto e il package sono segnaposto: non va eseguito senza sostituirli e verificarne target, stato e autorizzazioni.
DATA(environment) = xco_cp_generation=>environment->dev_system( 'X00K900001' ).
DATA(put_operation) = environment->create_put_operation( ).DATA(specification) = put_operation->for-dtel->add_object( 'ZDEMO_ID' ) ->set_package( 'ZDEMO' ) ->create_form_specification( ).
specification->set_short_description( 'Demo identifier' ).specification->set_data_type( xco_cp_abap_dictionary=>built_in_type->char( 10 )).
put_operation->execute( ).Il percorso espone cinque decisioni: ambiente, tipo dell’operazione, tipo repository, nome dell’oggetto e contenuto della specifica. Se ZDEMO_ID non esiste, il package è usato per la creazione; se esiste ed è aggiornato, il package fornito non ne cambia l’assegnazione. L’ambiente deriva da XCO_CP_GENERATION ed è sostenuto, nel modello documentato, da un Workbench transport in stato modificabile.
La sequenza reale di esecuzione
Sezione intitolata “La sequenza reale di esecuzione”Una pipeline affidabile tratta l’esecuzione come un confine, non come l’ultima riga di un builder:
- Verifica che trasporto e package siano coerenti e modificabili nel sistema target.
- Costruisce l’operazione e registra gli oggetti con specifiche tipizzate.
- Per i tipi con versioni inattive, crea o aggiorna quelle versioni.
- Esegue una mass activation degli oggetti raccolti, salvo uso esplicito dell’opzione
skip_activation. - Esegue sempre
COMMIT WORK. - In caso di fallimento, conserva eccezione e findings per oggetto.
Raccogliere in un solo PUT oggetti che supportano versioni inattive permette una mass activation comune e può gestire interdipendenze, anche circolari. Non trasforma però l’operazione in una transazione reversibile dall’esterno. Se l’attivazione fallisce, le versioni inattive già create non vengono cancellate automaticamente; una successiva diagnosi deve partire dallo stato effettivo del repository.
Il confine transazionale
Sezione intitolata “Il confine transazionale”Il COMMIT WORK eseguito da ogni operazione cambia il modo in cui va progettato il chiamante:
| Assunzione fragile | Conseguenza reale | Contromisura |
|---|---|---|
| “Eseguo più operazioni e poi decido se fare commit” | La prima execute ha già effettuato il commit |
Progettare ogni operazione come unità di persistenza |
| “Se la mass activation fallisce non resta nulla” | Possono restare versioni inattive | Ispezionare i findings e predisporre una riconciliazione |
| “DELETE riordina le dipendenze” | Ogni delete è costruito per un tipo; l’ordine tra tipi resta al chiamante | Eliminare prima i dipendenti, poi le dipendenze |
| “Catturo l’eccezione generica e ritento” | Il retry può incontrare stato già modificato | Leggere stato e findings prima di decidere |
Le eccezioni documentate CX_XCO_GEN_PUT_EXCEPTION, CX_XCO_GEN_PATCH_EXCEPTION e CX_XCO_GEN_DELETE_EXCEPTION rendono disponibili i findings incontrati durante l’esecuzione. Ridurle a un messaggio testuale significa perdere l’associazione tra problema e oggetto.
Disegnare l’automatore
Sezione intitolata “Disegnare l’automatore”Le Generation APIs rendono esplicito il piano di cambiamento prima di eseguirlo. Conviene separare specifiche ed esecuzione, registrare gli oggetti dell’operazione e trattare transport, activation e commit come parte dell’interfaccia dell’automatore. La generazione RAP completa mostra perché: una sola intenzione applicativa si distribuisce su molti object type.
Il frammento non è codice turnkey. Nomi, API, tipi e opzioni possono variare tra release e modalità di estensibilità. Prima dell’uso servono compilazione nel sistema target, autorizzazioni, transport target e una strategia per versioni inattive e cleanup. Non trasferire automaticamente queste API a un sistema on-premise.