XCO CTS: dal package al trasporto
Un flusso operativo XCO CTS per derivare il target, riusare o creare la request, verificare gli oggetti e rilasciare in ordine.
In breve
Sezione intitolata “In breve”XCO CTS collega una modifica ABAP al suo contenitore di trasporto: legge package, transport layer e target; interroga request e task; crea e rilascia trasporti Workbench o Customizing; espone proprietà ed entry. La sequenza affidabile non parte da un ID copiato in configurazione, ma dal confine che la modifica deve attraversare (Correction and Transport System).
Il flusso è: package → layer/target → lock/query/create → generation → inspect → release.
Workbench e Customizing non sono intercambiabili
Sezione intitolata “Workbench e Customizing non sono intercambiabili”| Scelta | Contenuto tipico | Origine del target | Evidenza da ispezionare |
|---|---|---|---|
| Workbench | Oggetti repository e modifiche indipendenti dal client | Transport layer del package strutturale | Object entry e oggetti repository localizzati sul trasporto |
| Customizing | Configurazione dipendente dal client | Target previsto dal processo di configurazione | Object entry più key entry delle righe di tabella |
Per una generazione repository, il package è la radice della decisione: XCO legge la sua transport layer e da questa ricava il transport target. Creare una Workbench request verso un target inserito a mano, senza confrontarlo con il package, è l’alternativa scartata: può produrre un contenitore formalmente valido ma incoerente con la linea di consegna.
La Customizing request non è un “Workbench più leggero”. Serve un contenuto diverso e può proseguire nel processo Business Configuration, per esempio tramite l’app di esportazione indicata da SAP. La scelta va quindi effettuata prima di creare la request, non corretta dopo aver registrato le entry.
Request e task: due responsabilità
Sezione intitolata “Request e task: due responsabilità”La request è il contenitore con tipo, owner, target, stato e attributi; il task è l’unità assegnata a chi registra le modifiche. In XCO un trasporto può rappresentare l’una o l’altro, ma espone sempre la request associata. La creazione Workbench documentata produce anche un task non classificato intestato all’utente attivo.
Prima di creare, conviene controllare se l’oggetto è già locked e risalire alla request che possiede il lock. In assenza di lock utile, una query può cercare task modificabili dello stesso owner e target e risolverli alle rispettive request. Solo quando nessuna request compatibile esiste si crea un nuovo contenitore. Questo evita di frammentare una singola modifica su più trasporti.
Flusso operativo
Sezione intitolata “Flusso operativo”- Leggere il package strutturale e derivare layer e target.
- Controllare il lock degli oggetti già esistenti; poi interrogare task modificabili per owner e target.
- Riusare la request associata oppure crearne una Workbench; creare Customizing soltanto per contenuto coerente con quel processo.
- Passare la Workbench request modificabile all’ambiente delle Generation APIs ed eseguire il piano.
- Rileggere proprietà, stato ed entry effettive; confrontarle con il piano previsto.
- Rilasciare prima tutti i task ancora modificabili, poi la request.
I primi tre passaggi possono essere condensati così. L’ultima istruzione crea davvero la request: va eseguita soltanto dopo i controlli di target e lock; il rilascio resta un’operazione successiva, dopo l’ispezione.
DATA(package_properties) = xco_cp_abap_repository=>package->for( 'ZDEMO_ROOT' )->read( ).
DATA(target) = package_properties-property-transport_layer ->get_transport_target( )->value.
DATA(request) = xco_cp_cts=>transports->workbench( target )->create_request( 'Generated repository objects' ).Caso anonimizzato: una pipeline genera un data element e una tabella nello stesso package. Il preflight trova la tabella già locked su una request aperta dello stesso target. La decisione corretta è fermarsi o riusare consapevolmente quella request; crearne una seconda non aggira il lock e nasconde il conflitto.
Ispezionare prima di rilasciare
Sezione intitolata “Ispezionare prima di rilasciare”Le Transport Read APIs distinguono object entry, identificate da program ID, tipo e nome, e key entry, che selezionano righe di tabella e hanno sempre una object entry corrispondente. Proprietà e attributi descrivono invece il contenitore (Transport Read APIs). Per Workbench la domanda è “sono presenti tutti gli oggetti attesi?”; per Customizing anche “le chiavi selezionano esattamente i record previsti?”. Il rilascio è l’ultimo gate, non il modo per scoprire cosa è stato registrato.
API, autorizzazioni, stati CTS e processi di esportazione variano tra prodotti e release. Il flusso non sostituisce policy di landscape, approvazioni o gestione degli errori. Lock e query sono controlli puntuali: tra verifica e generazione lo stato può cambiare. Occorre gestire conflitti e rileggere il trasporto dopo l’esecuzione.