ABAP Tier 1, 2 y 3 - Modelo de extensibilidad de tres niveles

Resumen

Este webinar se enfoca en el modelo de extensibilidad de tres capas (ABAP Tier Model) propuesto por SAP para entornos SAP S/4HANA On-Premise y Private Cloud, buscando mantener un Clean Core. Se explica la necesidad de este nuevo enfoque debido a los desafíos de las extensiones clásicas en las actualizaciones y migraciones. Se detalla la estructura: Tier 1 (basado en ABAP for Cloud Development, respeta el Clean Core), Tier 3 (ABAP clásico con objetos no permitidos en Tier 1, como BAPIs estándar) y Tier 2 (capa intermedia que encapsula llamadas a objetos de Tier 3 mediante wrappers – interfaces y clases – y las expone de forma controlada a Tier 1). Se demuestra cómo crear los paquetes, la interfaz, la clase wrapper y la clase factory en Tier 2, y cómo liberarlas (Release Contract C1) para su consumo desde Tier 1, respetando las restricciones del lenguaje ABAP Cloud. Se subraya la importancia de los Software Components para reforzar estas reglas.

Puedes ver la clase gratuita sobre este tema en nuestro canal de YouTube, donde podrás escuchar al docente hablar sobre este tema y las explicaciones que tiene para darte. Ver video aquí

Índice

Introducción: Necesidad de Extensibilidad en S/4HANA y Clean Core
Desafíos de la Extensibilidad Clásica y Objetivos del Nuevo Modelo
El Modelo de Extensibilidad de Tres Capas (ABAP Tier Model)
3.1. Tier 1: ABAP for Cloud Development (Clean Core)
3.2. Tier 3: ABAP Clásico (Legado)
3.3. Tier 2: El Puente (API Enablement, Wrappers)
Software Components y Gobernanza del Código
Demostración Práctica: Creación de Paquetes y Estructura
5.1. Paquete Tier 1 (Restringido a ABAP Cloud)
5.2. Paquete Tier 2 (Basado en ABAP Clásico)
Demostración Práctica: Restricciones en Tier 1
Demostración Práctica: Implementación en Tier 2
7.1. Creación de la Interfaz (Contrato Tier 1)
7.2. Creación de la Clase Wrapper (Llamada a BAPI – Tier 3)
7.3. Creación de la Clase Factory (Instanciación Segura)
Demostración Práctica: Liberación de Objetos de Tier 2 para Tier 1 (Release Contracts)
Demostración Práctica: Consumo desde Tier 1
Publicidad y Cierre

Conceptos Clave

Extensibilidad (Extensibility)
SAP S/4HANA Private Edition
SAP S/4HANA On-Premise
Clean Core
ABAP Tier Model (Modelo de 3 Capas)
Tier 1 (ABAP Cloud Development)
Tier 2 (API Enablement / Capa Intermedia)
Tier 3 (Classic ABAP / Legado)
ABAP for Cloud Development
Classic ABAP
Software Component
Wrappers (Clases de encapsulación)
Interface (ABAP OO)
Factory Class (Patrón Factory)
BAPI (Business Application Programming Interface)
Release Contract (C1 – Use in Cloud Development)
API Pública / Liberada
Eclipse ADT (ABAP Development Tools)
Key User Extensibility (Mencionado brevemente)
Developer Extensibility (On-Stack)
Side-by-Side Extensibility (Mencionado brevemente)
Upgrades

Introducción: Necesidad de Extensibilidad en S/4HANA y Clean Core

Este webinar se centra en el modelo de extensibilidad ABAP de tres capas (ABAP Tier Model), aplicable principalmente a entornos SAP S/4HANA Private Edition y On-Premise. Se aborda la necesidad constante de extender la funcionalidad estándar de SAP para cubrir requerimientos de negocio específicos, un factor clave en la consultoría técnica. El objetivo es entender cómo realizar estas extensiones manteniendo el núcleo limpio (Clean Core), una práctica esencial promovida por SAP.

Desafíos de la Extensibilidad Clásica y Objetivos del Nuevo Modelo

El modelo clásico de extensibilidad (user exits, BAdIs clásicas, modificaciones) presenta desafíos significativos durante las actualizaciones (upgrades) del sistema S/4HANA, pudiendo convertirlos en proyectos largos y costosos. El enfoque Clean Core busca mitigar esto al:

Evitar modificaciones directas a objetos estándar SAP.
Utilizar únicamente APIs públicas liberadas y puntos de extensión designados.
Facilitar upgrades más rápidos y sencillos.
Permitir una adopción ágil de nuevas funcionalidades e innovaciones.
Mientras que SAP S/4HANA Cloud Public Edition impone estrictamente el Clean Core, las ediciones Private Cloud y On-Premise ofrecen más flexibilidad, haciendo crucial la adopción voluntaria de estas buenas prácticas y modelos como el de tres capas.

El Modelo de Extensibilidad de Tres Capas (ABAP Tier Model)

Para entornos S/4HANA Private Edition y On-Premise donde puede ser necesario interactuar con funcionalidades clásicas (legado) que aún no tienen una API moderna liberada, SAP propone un modelo de tres capas lógicas:

3.1. Tier 1: ABAP for Cloud Development (Clean Core)

Es la capa donde se deben realizar los nuevos desarrollos y extensiones.
Utiliza exclusivamente la versión restringida del lenguaje ABAP for Cloud Development.
Solo permite el uso de objetos (clases, interfaces, CDS views, BAPIs modernas basadas en RAP, etc.) que han sido explícitamente liberados por SAP (o localmente bajo ciertas reglas) para este entorno.
Garantiza el cumplimiento del Clean Core.
El desarrollo se realiza típicamente con Eclipse ADT.

3.2. Tier 3: Classic ABAP (Legado)

Representa el código ABAP clásico existente en el sistema.
Incluye objetos estándar no liberados, módulos de función tradicionales (como BAPIs antiguas), Dynpros, Web Dynpros, etc.
Estos objetos no pueden ser llamados directamente desde Tier 1.

3.3. Tier 2: El Puente (API Enablement, Wrappers)

Actúa como una capa intermedia controlada para permitir la comunicación entre Tier 1 y Tier 3.
Se utiliza para encapsular la lógica o llamadas a objetos de Tier 3 (ej. una BAPI clásica) dentro de objetos desarrollados en Tier 2.
Estos objetos wrapper (típicamente clases ABAP OO) implementan una interfaz definida con sintaxis compatible con Tier 1.
La interfaz y una clase factory (que instancia el wrapper) son los únicos elementos de Tier 2 que se liberan para ser consumidos desde Tier 1.
El código dentro de los métodos del wrapper puede usar ABAP clásico (llamadas a BAPIs de Tier 3), pero esta complejidad queda oculta para Tier 1.
Este enfoque permite usar funcionalidad legada necesaria temporalmente, manteniendo el código de Tier 1 limpio y facilitando la futura refactorización cuando SAP libere una API moderna equivalente.

Software Components y Gobernanza del Código

Los Software Components juegan un papel crucial en la implementación técnica del modelo de tiers. Se pueden crear Software Components personalizados (diferentes del HOME clásico) y configurarlos para usar específicamente la versión de lenguaje ABAP for Cloud Development. Al asignar paquetes de desarrollo a estos componentes, Eclipse ADT y el sistema ABAP realizan chequeos de sintaxis y de uso de objetos, impidiendo el uso de código clásico o APIs no liberadas dentro del código destinado a Tier 1, reforzando así la gobernanza Clean Core.

Demostración Práctica: Creación de Paquetes y Estructura

Se muestra la creación de dos paquetes de desarrollo en Eclipse ADT:

5.1. Paquete Tier 1 (Restringido a ABAP Cloud)

Se crea un paquete (ej. ZWEBER_TIER1) asignado a un Software Component configurado para ABAP for Cloud Development.
Este paquete hereda las restricciones de lenguaje y uso de objetos.

5.2. Paquete Tier 2 (Basado en ABAP Clásico)

Se crea otro paquete (ej. ZWEBER_TIER2) asignado al Software Component estándar (HOME o uno configurado para ABAP Clásico).
Este paquete permite el uso de sintaxis y objetos clásicos.

Demostración Práctica: Restricciones en Tier 1

Se crea una clase ABAP dentro del paquete Tier 1. Se intenta:

Declarar una variable usando TYPE MARA: Falla porque MARA (tabla estándar) no está liberada para ABAP Cloud.
Hacer un SELECT de una tabla estándar (T005): Falla por la misma razón. Se muestra que sí permite usar la CDS View liberada (I_Country).
Llamar a un módulo de funciones clásico (BAPI BAPI_PR_CREATE): Falla porque CALL FUNCTION no está permitido o la BAPI no está liberada para Tier 1.
Esto demuestra las restricciones impuestas por el entorno ABAP Cloud Development.

Demostración Práctica: Implementación en Tier 2

Dentro del paquete Tier 2 (ABAP Clásico), se implementa la solución para encapsular la BAPI BAPI_PR_CREATE:

7.1. Creación de la Interfaz (Contrato Tier 1)

Se crea una interfaz ABAP OO (ej. ZIF_WEBER_WRAPPER_BAPI_PR) utilizando únicamente sintaxis y tipos de datos compatibles con ABAP Cloud.
Se define la firma de los métodos necesarios (ej. CREATE, CHECK) que reflejan la funcionalidad de la BAPI, pero usando tipos de datos liberados o tipos definidos dentro de la propia interfaz (que también deben ser compatibles con Tier 1).

7.2. Creación de la Clase Wrapper (Llamada a BAPI – Tier 3)

Se crea una clase ABAP OO (ej. ZCL_WEBER_WRAPPER_BAPI_PR) que implementa la interfaz anterior.
Dentro de los métodos de esta clase (que pueden usar ABAP clásico porque están en Tier 2), se implementa la lógica real de llamada a la BAPI BAPI_PR_CREATE, mapeando los parámetros de la interfaz a los parámetros de la BAPI.
Se pueden crear métodos privados adicionales para organizar la lógica (ej. prepare_header, call_bapi).

7.3. Creación de la Clase Factory (Instanciación Segura)

Se crea otra clase ABAP OO (ej. ZCL_WEBER_WRAPPER_FACTORY_PR) diseñada para ser el punto de entrada desde Tier 1.
Se define un método estático público (ej. create_instance) que devuelve un objeto de tipo TYPE REF TO ZIF_WEBER_WRAPPER_BAPI_PR (la interfaz).
Dentro de este método, se crea una instancia de la Clase Wrapper (CREATE OBJECT ro_instance TYPE zcl_weber_wrapper_bapi_pr.) y se asigna a la variable de retorno (que es de tipo interfaz).
El constructor de la Clase Factory puede ser privado para asegurar que la instanciación se haga solo a través del método estático.

Demostración Práctica: Liberación de Objetos de Tier 2 para Tier 1 (Release Contracts)

Para que los objetos de Tier 2 puedan ser utilizados desde Tier 1, deben ser explícitamente liberados:

Se accede a las propiedades de la Interfaz (ZIF_…) y de la Clase Factory (ZCL_…_FACTORY_…) en Eclipse ADT.
En la pestaña “API State”, se añade un Release Contract seleccionando C1 – Use in Cloud Development.
Se activa esta configuración.
Importante: La Clase Wrapper (ZCL_…_WRAPPER_…) no se libera para Tier 1, ya que contiene código clásico no permitido.

Demostración Práctica: Consumo desde Tier 1

Se vuelve a la clase creada en el paquete Tier 1.
Ahora, es posible declarar una variable de tipo referencia a la interfaz liberada (DATA(lo_pr_api) TYPE REF TO zif_weber_wrapper_bapi_pr.).
Se puede llamar al método estático de la Clase Factory liberada para obtener la instancia (lo_pr_api = zcl_weber_wrapper_factory_pr=>create_instance( ).).
Se pueden invocar los métodos definidos en la interfaz sobre la instancia obtenida (lo_pr_api->create(…)).
El sistema permite esta llamada porque interactúa solo con objetos (interfaz y factory) que tienen el contrato C1 y cuya firma es compatible con ABAP Cloud. La llamada real a la BAPI clásica permanece encapsulada y oculta dentro del wrapper en Tier 2.

Conclusión

El modelo ABAP de tres capas es una estrategia clave para gestionar la extensibilidad en SAP S/4HANA On-Premise y Private Edition dentro del paradigma Clean Core. Permite aprovechar inversiones existentes en lógica clásica (como BAPIs) de forma controlada desde el moderno entorno ABAP Cloud (Tier 1), utilizando una capa intermedia (Tier 2) con interfaces y factories liberadas explícitamente. Aunque introduce una capa adicional de desarrollo, este enfoque promueve la mantenibilidad, facilita los upgrades y alinea estos sistemas con la dirección estratégica de SAP hacia la nube.

Recomendación de Curso

Basado en el contenido del texto, el curso más relevante de Logali Group es la Formación de Extensibilidad en S/4HANA Cloud (Clean Core) Ver aquí

Justificación: El webinar se centra específicamente en el modelo de extensibilidad de tres capas y cómo mantener el Clean Core al interactuar con código clásico, un tema avanzado dentro de ABAP Cloud.

Gheorghe Valer

Deja una respuesta Cancelar la respuesta

Acceder