Diagnostica delle XCO Generation APIs

Come trasformare un fallimento POST, PUT, PATCH o DELETE in findings attribuibili e in una decisione di recupero.

Riferimento tecnicoAggiornato il 3 settembre 20265 min di lettura

In breve

Le XCO Generation APIs non espongono un unico errore generico. Ogni famiglia di operazioni definisce una propria eccezione e rende disponibili i findings prodotti durante l’esecuzione. Il dato utile non è soltanto che una PUT sia fallita, ma quali oggetti abbiano generato messaggi e in quale fase sia rimasto il repository. Questa distinzione è necessaria perché un’operazione può coinvolgere più object type, eseguire una mass activation e lasciare versioni inattive dopo un fallimento (Generation Error Handling).

Eccezioni come parte del contratto

Operazione	Eccezione documentata
`POST`	`CX_XCO_GEN_POST_EXCEPTION`
`PUT`	`CX_XCO_GEN_PUT_EXCEPTION`
`PATCH`	`CX_XCO_GEN_PATCH_EXCEPTION`
`DELETE`	`CX_XCO_GEN_DELETE_EXCEPTION`

Catturare la classe specifica preserva il significato dell’operazione fallita. L’eccezione offre l’insieme dei findings e viste filtrate per object type. Questo permette, per esempio, di separare i messaggi di una table type da quelli di un data element presente nella stessa PUT. Convertire subito l’eccezione in una stringa elimina proprio l’associazione necessaria alla diagnosi.

Un fallimento a cascata

Il sample SAP costruisce intenzionalmente due specifiche non valide: un data element riferisce un dominio inesistente e una table type usa quel data element. Il caso mostra perché “il primo messaggio” non basta: un difetto alla base del grafo può produrre findings su più oggetti dipendenti.

Un estratto sanitizzato mantiene sia la vista completa sia quella circoscritta:

TRY.
    put_operation->execute( ).
  CATCH cx_xco_gen_put_exception INTO DATA(error).
    DATA(all_findings) = error->findings.
    DATA(table_type_findings) = error->findings->for->ttyp.
ENDTRY.

Il filtro FOR->TTYP non dichiara automaticamente la causa primaria; restringe il perimetro ai findings associati alle table type. La diagnosi deve poi ricostruire la dipendenza: oggetto mancante, specifica incompatibile, problema di attivazione oppure vincolo di package e trasporto.

Dal finding alla decisione

Un flusso di recupero prudente è:

catturare l’eccezione specifica senza perdere i findings;
raggruppare i messaggi per object type e nome;
distinguere costruzione, scrittura e mass activation;
rileggere lo stato effettivo degli oggetti coinvolti, quando l’object type lo supporta;
correggere la specifica oppure predisporre un cleanup esplicito;
eseguire una nuova operazione soltanto dopo avere rivalutato le dipendenze.

La rilettura al punto 4 è essenziale. Per gli oggetti che supportano versioni inattive, una mass activation fallita non elimina automaticamente quanto è già stato scritto. Inoltre ogni esecuzione di un’operazione effettua COMMIT WORK: più chiamate execute non formano un rollback applicativo unico (Design of the XCO Generation APIs).

Diagnostica di una generazione RAP

In un business object RAP generato, un errore del service binding può avvenire dopo che dominio, tabella, CDS, behavior e service definition sono già stati eseguiti in un’altra operazione. Il finding del binding non dimostra quindi che l’intero business object sia assente. Il resoconto dovrebbe indicare almeno operazione, oggetto, fase, finding e stato riletto; soltanto questi dati consentono di scegliere tra completamento, rigenerazione e teardown.

Limiti

I findings descrivono ciò che l’esecuzione ha rilevato; non garantiscono ordinamento causale, rollback o idempotenza del retry. Classi di eccezione, object type supportati e struttura delle viste filtrate sono dipendenti dalla release. Gli esempi richiedono un package e un Workbench transport validi nel sistema target. Non ricostruire firme da frammenti di documentazione incompleti: verificare sempre il SAP Help e il completamento ADT della release in uso.