Componentes de software en ABAP Cloud: quién puede llamar a quién

Quien empieza a escribir código en ABAP Cloud en S/4HANA pronto se topa con un mensaje como "The use of Class ZCL_... is not permitted" al llamar a una clase Z que ya existe. La reacción habitual es convertir también la clase llamada a ABAP Cloud. Muchas veces no sirve de nada: el error persiste. La explicación está en un concepto poco comentado, el componente de software.

Qué es un componente de software

Un componente de software es un conjunto de paquetes que forma una unidad de entrega: se versiona, se instala y se actualiza como un bloque. El propio S/4HANA está hecho de ellos. En Sistema → Status, en la lista de componentes instalados, aparecen nombres como SAP_BASIS (la base técnica), SAP_ABA y S4CORE (el núcleo de S/4HANA), cada uno con su versión y su nivel de Support Package.

El código de la empresa también vive en componentes:

• todo paquete pertenece a exactamente un componente, y todo objeto pertenece a un paquete. La jerarquía es componente → paquete → objeto;
• los paquetes Z quedan, por defecto, en el componente HOME, que existe en todo sistema para el desarrollo del cliente. Muchas empresas tienen todo su código Z en él, sin haber pensado nunca en el tema;
• la empresa puede crear sus propios componentes, por ejemplo uno para el código nuevo y otro para el legado, y elegir en cuál de ellos queda cada paquete;
• en SAP BTP ABAP Environment, cada componente corresponde a un repositorio Git, lo que hace más visible la idea de "unidad de entrega".

Para quien viene de otros lenguajes, la analogía más cercana es la de un módulo: un límite alrededor de un conjunto de código, que indica qué le pertenece. En el ABAP clásico, ese límite casi no tenía efecto en el día a día. En ABAP Cloud, pasa a decidir quién puede llamar a quién.

Dónde vive la "marca" de ABAP Cloud

La versión de lenguaje aparece en tres lugares, y cada uno cumple un papel:

El componente de software lo configura la administración del sistema (en S/4HANA, con el report RSMAINTAIN_SWCOMPONENTS) y tiene dos características: si es transportable o local, y qué versión de lenguaje acepta.

El componente por defecto de los objetos Z suele ser HOME, que es "Standard ABAP", es decir, sin restricción.

La regla: quién puede llamar a quién

Un objeto en ABAP estándar llama a cualquier cosa: la regla solo se aplica a quien está en ABAP Cloud. Para él, lo que decide es el componente de software del objeto llamado:

El detalle que sorprende: la regla se aplica incluso cuando el objeto llamado ya es ABAP Cloud. Una clase ABAP Cloud en otro componente, sin C1, sigue siendo inaccesible. Y lo contrario también es cierto: un objeto en ABAP estándar con C1 puede ser llamado por código ABAP Cloud de otro componente. Así es exactamente como funciona un wrapper.

Existe una excepción documentada por SAP: las Software Component Relations, que permiten a un componente ABAP Cloud usar objetos de otro componente ABAP Cloud sin liberar cada uno de ellos. La documentación no indica a partir de qué release de S/4HANA on-premise está disponible el recurso. Sin una relación configurada, se aplica la regla de la tabla.

El C1 libera el uso, no limpia la deuda

La liberación C1 es un contrato: el objeto pasa a poder ser usado por código ABAP Cloud de otros componentes, y quien lo libera se compromete a no hacer cambios incompatibles en él. En un objeto Z, quien hace cumplir ese compromiso es el ATC de compatibilidad de API, con una instantánea (snapshot) de la API tomada antes, no la activación (véase Contratos de liberación de API: qué garantizan C0, C1, C2, C3 y C4). La liberación no cambia nada en los hallazgos del propio objeto. Un wrapper con C1 que lee una tabla de SAP sigue teniendo el hallazgo de nivel C.

Además, las llamadas entre objetos Z nunca generan hallazgos en el check de Clean Core: este solo evalúa el uso de objetos de SAP. Esto tiene una consecuencia importante:

• un objeto ABAP Cloud queda en el nivel A aunque llame, en el mismo componente, a un objeto Z estándar de nivel C;
• la deuda existe, pero vive en el vecino, y no aparece en el objeto A.

Por qué separar el código ABAP Cloud en un componente propio

Si el código ABAP Cloud queda en un componente sin restricción, junto con el legado, puede llamar a cualquier objeto Z antiguo sin contrato. El resultado es un nivel A con dependencias ocultas.

Con el código ABAP Cloud en un componente que solo acepta ABAP Cloud, toda dependencia del legado pasa a exigir un objeto con C1. Cada dependencia se convierte en un contrato explícito, revisado y visible, y la deuda queda concentrada en los wrappers. Es también la orientación del ABAP Extensibility Guide de SAP: código ABAP Cloud en un componente de ABAP Cloud, código clásico en HOME o en un componente clásico.

SAP organizaba esto en el antiguo modelo de tres capas. Desde agosto de 2025 habla de niveles A a D y de "desarrollo ABAP Cloud" y "desarrollo ABAP clásico", pero la separación en capas sigue siendo una forma práctica de organizar los componentes:

Dentro de la capa 2, solo la clase que realmente llama a SAP necesita ser ABAP estándar. La interfaz del wrapper puede ser ABAP Cloud en el mismo componente, y el panel muestra un único objeto fuera del nivel A por wrapper.

Tres precauciones prácticas

• La variante de preparación para ABAP Cloud (ABAP_CLOUD_READINESS) anticipa la regla. Ejecutado sobre un objeto estándar, señala las llamadas a objetos Z de otro componente sin C1, que impedirían la conversión. Las llamadas dentro del mismo componente y a objetos con C1 no aparecen.
• Cambiar el componente de un paquete exige que los objetos ya estén en ABAP Cloud, cuando el componente nuevo solo acepta ABAP Cloud. Primero se convierte, después se cambia el componente.
• Revocar el C1 antes de borrar un objeto liberado que nadie usa. Si se borra con el contrato activo, el registro de liberación queda huérfano y la orden de transporte con el borrado no se libera. Si alguien usa el objeto, el camino es marcarlo como obsoleto, con un sucesor.

Para ver cómo el wrapper aprovecha esta regla, véase Wrapper en Clean Core: la deuda se concentra, no desaparece. Para entender por qué el nivel A exige ABAP Cloud, véase Por qué un programa con pantalla clásica se queda en el nivel B.

Fuentes

• SAP, Extend SAP S/4HANA in the cloud and on premise with ABAP based extensions (ABAP Extensibility Guide), versión 2.3, agosto de 2025, capítulo 5.
• SAP Help, ABAP Development Tools, Released APIs y Software Component Relations.
• Pruebas de llamadas entre componentes en un SAP S/4HANA 2025 (SAP_BASIS 816), con clases en los componentes HOME, en un componente solo de ABAP Cloud y en LOCAL.