La usage list: cómo saber, en frío, si una clase está liberada

Ya hemos dicho que en Clean Core solo consumes objetos liberados. Suena fácil hasta que estás delante de una clase CL_... que hace exactamente lo que necesitas y no sabes si puedes tocarla. Este post va de esa comprobación concreta, la que separa una suposición de una certeza.

”Existe” no es “está liberado”

En un sistema on-premise clásico podías llamar a casi cualquier cosa que compilara. En ABAP for Cloud Development eso se acabó: el lenguaje está restringido y solo ves los objetos que SAP ha marcado como usables. Que un objeto aparezca no significa que esté liberado para tu escenario. La liberación es un contrato con tres piezas:

• El estado de release: released o no released. Sin release, estás fuera del contrato.
• El contract type: para qué uso lo libera SAP. No es lo mismo “use system-internally” que “use as remote API”.
• La estabilidad garantizada: SAP se compromete a no romper la firma de lo liberado entre releases. De lo no liberado no promete nada.

Cómo se comprueba de verdad

No adivines por el prefijo del nombre. Comprueba. En ADT tienes tres caminos que se complementan:

1. El propio compilador de ABAP Cloud: si escribes contra algo no liberado, la comprobación de sintaxis del lenguaje restringido te lo marca al instante. Es tu primera red.
2. El release contract del objeto: en las propiedades del objeto (o en su cabecera) ves si está released y con qué contract type. Ahí decides si tu uso encaja.
3. La usage list (dónde se usa): te dice quién consume ese objeto. Sirve para el camino inverso: si vas a extender algo, saber quién depende de ello antes de tocarlo.

“Compila” no es “está liberado”, y “está liberado” no es “liberado para lo que yo quiero”. Son tres puertas distintas y hay que pasar las tres.

flowchart TD
 A["Quiero usar un objeto estándar"] --> B["¿El compilador ABAP Cloud lo acepta?"]
 B -->|No| X["No liberado: busca la released API equivalente"]
 B -->|Sí| C["¿Estado = released?"]
 C -->|No| X
 C -->|Sí| D["¿Contract type encaja con mi uso?"]
 D -->|No| X
 D -->|Sí| E["Usar, envuelto tras interfaz propia"]

Un ejemplo que falla y otro que pasa

El primero compila en on-premise y revienta en ABAP Cloud, porque VBAK no es un objeto liberado para acceso directo:

" NO liberado en ABAP for Cloud Development: el compilador lo rechaza
SELECT SINGLE * FROM vbak
  WHERE vbeln = @iv_order
  INTO @DATA(ls_header).

El segundo usa la CDS liberada equivalente, que sí es un contrato estable:

" Liberada como released CDS: contrato estable entre upgrades
SELECT SINGLE salesorder, soldtoparty, totalnetamount
  FROM i_salesorder
  WHERE salesorder = @iv_order
  INTO @DATA(ls_header).

La diferencia no es de estilo: es que el primero puede romperse en cualquier feature pack sin aviso y el segundo no.

El hábito que te ahorra el retrabajo

Antes de teclear el nombre de cualquier objeto estándar, para y responde tres preguntas: está released, con qué contract type, y encaja con lo que voy a hacer. Treinta segundos. Si la respuesta a alguna es “no”, casi siempre existe una released API equivalente; y si de verdad no existe, ese es tu caso legítimo para documentar una excepción, no para saltarte el contrato en silencio.

En el próximo post bajamos al detalle de ABAP SQL en ABAP Cloud: qué cambia respecto al clásico cuando el lenguaje deja de dejarte hacer lo que antes hacías sin pensar.