XCO Read APIs: handle, contenuto e origine
Come leggere oggetti e parti del repository ABAP distinguendo identità, contenuto, versione, provenienza e cache.
In breve
Sezione intitolata “In breve”Le XCO Read APIs espongono il contenuto degli oggetti del repository ABAP attraverso un modello gerarchico e tipizzato. La radice rappresenta l’oggetto; i nodi successivi rappresentano parti come campi, metodi o parametri. La distinzione decisiva è tra handle, che identifica cosa leggere, e content handle, che espone gli attributi leggibili. Quando l’object type lo supporta, un’origine stabilisce anche dove eseguire la lettura. Questo disegno evita di confondere nome, versione e provenienza dello stesso oggetto (Read APIs).
Tre coordinate separate
Sezione intitolata “Tre coordinate separate”| Coordinata | Domanda | Esempio |
|---|---|---|
| Object o part handle | Quale oggetto o parte? | Campo KEY_FIELD della tabella ZDEMO |
| Content handle | Quali attributi? | Tipo, indicatore di chiave, descrizione |
| Origin | Da quale sistema e con quale cache? | Default locale, local configurato o remote |
Un handle conserva gli identificatori semantici e permette di verificare l’esistenza tramite EXISTS. Il metodo CONTENT conduce alla rappresentazione leggibile. Da lì, GET restituisce insieme gli attributi disponibili, mentre i metodi GET_* leggono proprietà singole. Per gli oggetti che supportano più versioni, la scelta tra stato attivo e inattivo precede l’accesso al contenuto.
Questa separazione è utile anche nei controlli automatici: si può costruire il riferimento senza leggere il database, verificare l’esistenza e acquisire soltanto la parte necessaria. Gli attributi dipendenti dalla lingua, come le descrizioni brevi, vengono restituiti nella lingua originale dell’oggetto, non automaticamente nella lingua di logon.
Una lettura concreta
Sezione intitolata “Una lettura concreta”Il seguente frammento sanitizzato legge un campo di tabella senza manipolare sorgente testuale:
DATA(field) = xco_cp_abap_dictionary=>database_table( 'ZDEMO' )->field( 'KEY_FIELD' ).
IF field->exists( ). DATA(content) = field->content( )->get( ).ENDIF.field identifica tabella e nome del campo; content contiene gli attributi esposti per quel nodo. Per una classe, lo stesso modello attraversa definizione, sezione pubblica, componenti, metodo, parametri ed eccezioni. L’implementazione del metodo è un nodo separato e può fornire il sorgente come insieme di righe (Reading a Class).
Origini e cache
Sezione intitolata “Origini e cache”| Origine | Lettura | Comportamento documentato |
|---|---|---|
| Default | Sistema locale | Prima lettura dal database, poi cache per la sessione ABAP |
| Local | Sistema locale | Strategia di cache configurabile per gli object type supportati |
| Remote | Destinazione RFC | Lettura e cache configurabili dove l’object type offre questa origine |
La matrice di supporto non è uniforme. Classi e interfacce offrono un’origine remota comune tramite XCO_CP_ABAP_OBJECTS=>ORIGIN; altri object type possono offrire soltanto default e local, oppure non esporre ancora il concetto di origin. Non si deve quindi trasferire la capacità osservata su una classe a domini, CDS o service binding senza consultare la pagina corrente dell’oggetto.
Il confine remoto
Sezione intitolata “Il confine remoto”Una remote origin usa un oggetto IF_RFC_DEST ottenuto dal destination provider. La documentazione corrente limita questa lettura remota di classi e interfacce a sistemi sorgente on-premise; SAP Public Cloud non è indicato come sorgente supportato. L’utente remoto necessita inoltre delle autorizzazioni S_RFC documentate per i function module di type information, oppure per il function group SEO_REMOTE (Reading from a remote destination).
L’origine remota non trasforma la lettura in replica. Identità, versione richiesta, autorizzazioni e stato del sistema sorgente rimangono parte del risultato da interpretare.
Supporto di origin, versioni e parti leggibili varia per object type e release. Le matrici di una release precedente non vanno pubblicate come capacità correnti. Una lettura riuscita non certifica che l’oggetto rispetti un contratto di rilascio per l’uso applicativo, né che il contenuto remoto coincida con quello locale. Prima di costruire confronti o generatori, verificare documentazione e firme disponibili nel sistema target.