Contratti di rilascio in ABAP Cloud

Come scegliere e governare i contratti C0–C4 senza confondere un API state con una promessa assoluta di compatibilità.

Riferimento tecnicoAggiornato il 3 settembre 20265 min di lettura

In breve

Un contratto di rilascio descrive per quale uso un oggetto ABAP diventa API e quali controlli di consistenza e compatibilità ne conseguono. Non è un bollino generico di qualità. C0 abilita estensioni, C1 il consumo locale, C2 l’integrazione remota, C3 la gestione di contenuto di configurazione e C4 l’uso da AMDP. Visibilità e release contract formano quindi una decisione architetturale, non una proprietà da impostare a fine sviluppo (Public Released APIs).

Matrice C0–C4

Contratto	Scopo dichiarato	Confine da verificare
C0 — Extend	Stabilità di extension point dedicati	Tipo di estensione e visibilità ammesse
C1 — Use System-Internally	Interfaccia locale stabile per sviluppo custom	Consumo nel sistema e tra componenti software
C2 — Use as Remote API	Interfaccia stabile per integrazione o side-by-side	Protocollo, semantica remota e ciclo di deprecazione
C3 — Manage Configuration Content	Persistenza stabile del contenuto di configurazione	API ed editor previsti per export, import e manutenzione
C4 — Use in AMDP	Interfaccia tecnica stabile consumabile da AMDP	Il metodo AMDP deve essere rilasciato anche con C1

Per C0 e C1 entra in gioco anche la visibilità: Use in Cloud Development e, dove previsto, Use in Key User Apps. La documentazione ADT segnala inoltre che, lato cliente, i contratti esplicitamente rilasciabili sono C0 e C1; per C0 la visibilità è limitata a Cloud Development (Released APIs).

SET_API_STATE è un atto, non la prova

XCO espone SET_API_STATE e GET_API_STATE per diversi oggetti repository, tra cui classi, interfacce, entità CDS e tipi Dictionary. L’impostazione avviene dentro uno scenario di modifica associato a un trasporto (API Release Framework).

Il successo di SET_API_STATE prova che lo stato è stato registrato nel contesto accettato dal sistema. Non prova che il contratto scelto sia adeguato ai consumatori, che il comportamento applicativo sia stabile, né che le modifiche future siano compatibili. Prima del rilascio servono almeno: perimetro dei consumer, ownership, semantica degli errori, strategia di deprecazione e verifica delle dipendenze rilasciate.

Caso concreto: una classe pensata per due componenti dello stesso sistema appartiene normalmente al ragionamento C1. Marcarla C2 non è una scorciatoia disponibile: le classi custom non rientrano negli object type del contratto C2. Se serve consumo remoto, occorre progettare una superficie C2 supportata e definirne serializzazione, autorizzazione e comportamento di rete (Use as Remote API).

Released non significa immutabile

Un oggetto released non è immutabile e la compatibilità non è assoluta. SAP definisce cambiamenti ammessi e vietati per contratto e tipo di oggetto; il consumer deve tollerare quelli compatibili e seguire il ciclo Released → Deprecated →, dove previsto, Decommissioned. La promessa riguarda il contratto dichiarato, non ogni dettaglio osservabile accidentalmente.

Per governare l’evoluzione, l’ATC check API_COMPATIBILITY confronta gli oggetti rilasciati con un API snapshot. Senza uno snapshot check-relevant, il controllo non ha la base storica necessaria (Checking the Compatibility of Released APIs). Il gate utile è quindi: review del contratto, release trasportata, snapshot e controllo sulle modifiche successive.

Limiti

Contratti disponibili, tipi rilasciabili e visibilità dipendono da prodotto, release e modalità di estensibilità. La matrice orienta la scelta, ma non sostituisce le regole di consistenza per il singolo object type né la verifica nel sistema target. Anche l’automazione XCO va collegata a un trasporto coerente e alle autorizzazioni reali.