Principi della XCO Library
Come moduli, valori enumerati ed eccezioni costruiscono un vocabolario scopribile per lo sviluppo ABAP Cloud.
In breve
Sezione intitolata “In breve”XCO, acronimo di Extension Components, è una libreria general-purpose per lo sviluppo ABAP. L’edizione Cloud Platform è destinata agli scenari ABAP su SAP BTP. Il suo valore non consiste nel rendere brevi tutte le operazioni, ma nel renderle scopribili e componibili: una classe pubblica conduce al modulo, gli enumerati sostituiscono molte stringhe libere e le eccezioni seguono una strategia comune. Sono principi di disegno documentati da SAP, non la garanzia che ogni API esista in ogni release (XCO Library).
Tre principi, tre errori evitati
Sezione intitolata “Tre principi, tre errori evitati”| Principio | Contratto osservabile | Errore che riduce |
|---|---|---|
| Moduli | Ogni modulo espone una classe API con prefisso XCO_CP_ |
Cercare classi interne o costruire dipendenze su superfici non rilasciate |
| Valori enumerati | I valori ammessi sono oggetti pre-creati raggiungibili dalla classe API | Ricostruire costanti testuali, casing e conversioni a ogni chiamata |
| Eccezioni | Le eccezioni runtime sollevate esplicitamente da XCO condividono la radice CX_XCO_RUNTIME_EXCEPTION |
Trattare ogni modulo come un sistema d’errore incompatibile |
Questa uniformità è utile soprattutto in ADT. A partire, per esempio, da XCO_CP_ABAP_DICTIONARY, il completamento del codice mostra le astrazioni disponibili e i valori accettati. La classe API è quindi insieme facciata pubblica e indice navigabile del modulo (Core principles).
Un vocabolario che attraversa gli oggetti
Sezione intitolata “Un vocabolario che attraversa gli oggetti”Le API di generazione distinguono le operazioni specifiche di un tipo dalle astrazioni concettuali riutilizzabili. Un tipo built-in del Dictionary, per esempio, può descrivere il formato di un dominio, il tipo di un data element oppure la riga di una table type. Lo stesso oggetto tipizzato può essere costruito una volta e passato a specifiche diverse:
DATA(char_10) = xco_cp_abap_dictionary=>built_in_type->char( 10 ).
domain_specification->set_format( char_10 ).data_element_specification->set_data_type( char_10 ).table_type_specification->set_row_type( char_10 ).Il frammento illustra il modello, non un programma autonomo: le tre specifiche devono essere ottenute dalle rispettive API di generazione e la loro disponibilità va controllata nel sistema target. Il vantaggio architetturale è concreto: “carattere lungo 10” rimane lo stesso concetto nei tre contesti, invece di essere riscritto in tre forme potenzialmente divergenti (Design of the XCO Generation APIs).
Enumerati: oggetti, non codici decorati
Sezione intitolata “Enumerati: oggetti, non codici decorati”Un enumerato XCO può esporre proprietà specifiche e il valore primitivo sottostante. Non è soltanto una costante con un nome più lungo. Quando un’API accetta, per esempio, una delivery class, il percorso dalla classe del modulo al valore ammesso rende visibile il dominio direttamente nel codice.
Il controesempio è passare un carattere ricostruito a memoria perché “nel sistema vale A”. Anche se una conversione lo rende compilabile, il chiamante ha perso la scoperta guidata, il controllo del tipo e il significato dichiarato dal modulo. La regola pratica è: se la classe API espone un enumerato, usare quell’oggetto; ricorrere al valore primitivo solo al confine che lo richiede.
Errori: recuperabili e non recuperabili
Sezione intitolata “Errori: recuperabili e non recuperabili”La strategia XCO separa due casi. Se il chiamante può realisticamente reagire — l’acquisizione di un lock esclusivo è l’esempio della documentazione — l’errore appartiene al flusso applicativo. Negli altri casi la libreria privilegia eccezioni no_check. Questo non significa ignorarle: significa evitare firme cariche di eccezioni che il chiamante potrebbe soltanto propagare.
Per il codice che orchestra più moduli, CX_XCO_RUNTIME_EXCEPTION offre una radice comune per logging e confini di errore. Catturarla indiscriminatamente e continuare, però, annulla l’informazione: nelle operazioni di generazione le eccezioni specifiche espongono anche i findings per oggetto, che vanno conservati nel resoconto del fallimento.
Perché conta
Sezione intitolata “Perché conta”XCO è più convincente quando viene trattata come linguaggio di dominio del repository, non come generatore di testo ABAP. Modulo, enumerato e astrazione concettuale restringono lo spazio delle scelte prima dell’esecuzione. È questo il collegamento con la generazione di un business object RAP: la complessità non scompare, ma diventa una catena di contratti tipizzati e ispezionabili.
Il prefisso XCO_CP_ identifica la convenzione delle API pubbliche documentate, ma non autorizza l’uso di classi interne. Moduli, metodi, object type supportati e modalità di estensibilità variano con la release. Gli esempi vanno compilati nel sistema ABAP Cloud di destinazione e confrontati con la documentazione della relativa versione; non sono indicazioni valide automaticamente per un sistema ABAP on-premise o per release precedenti.