Wrappers para código legacy: consumir lo viejo sin contaminar lo nuevo

Ningún proyecto real empieza en verde. Tienes una base de ABAP clásico que funciona, que nadie va a reescribir este trimestre, y a la vez tienes que construir la capa nueva en ABAP Cloud. La tentación es o bien tirar todo abajo (imposible) o bien llamar al legacy directamente desde lo nuevo (veneno). Hay una tercera vía, y tiene nombre: wrappers.

El problema en una frase

El código clásico usa cosas que en ABAP Cloud no existen: acceso directo a tablas, function modules no liberados, sentencias del lenguaje sin restringir. Si lo llamas a pelo desde tu capa cloud, arrastras todo eso a tu código nuevo y lo primero que ocurre es que ni compila. Y aunque compilara por algún puente, habrías acoplado tu capa limpia a lo más frágil del sistema.

Los niveles de ABAP te dan la pista

SAP ya definió cómo convive lo viejo con lo nuevo, y encaja aquí:

• Tier 1, ABAP for Cloud Development: tu capa nueva, limpia, cloudready.
• Tier 2, APIs desde el ABAP clásico: el puente. Expones la funcionalidad legacy como una API estable y controlada.
• Tier 3, ABAP clásico: el código viejo, que se queda donde está, sin tocar.

La estrategia de wrappers es, ni más ni menos, materializar el Tier 2: envolver el Tier 3 tras una interfaz que el Tier 1 pueda consumir sin enterarse de lo que hay detrás.

Un wrapper bien hecho es una promesa: “prometo que mi capa nueva solo conoce esta firma, y el día que reescriba lo de dentro no se entera nadie”.

flowchart TD
 A["Capa nueva (Tier 1) ABAP for Cloud Development"] --> B["Interfaz del wrapper firma estable"]
 B --> C["Wrapper / API (Tier 2) traduce y aísla"]
 C --> D["Código legacy (Tier 3) tablas, FMs, ABAP clásico"]
 A -.->|"llamada directa PROHIBIDA"| D

El patrón, en dos piezas

Primero, la interfaz: es el único contrato que tu capa cloud conoce. Nada de tipos del legacy asomando por aquí, solo tipos limpios de tu dominio.

INTERFACE zif_customer_credit
  PUBLIC.
  TYPES: BEGIN OF ty_credit,
           customer     TYPE i_customer-customer,
           credit_limit TYPE p LENGTH 15 DECIMALS 2,
         END OF ty_credit.

  METHODS get_credit
    IMPORTING iv_customer      TYPE i_customer-customer
    RETURNING VALUE(rs_credit) TYPE ty_credit.
ENDINTERFACE.

Segundo, la implementación del wrapper: aquí, y solo aquí, vive el contacto con lo viejo. Si mañana ese cálculo pasa a una released API, cambias esta clase y nadie más se entera.

CLASS zcl_customer_credit DEFINITION
  PUBLIC FINAL CREATE PUBLIC.
  PUBLIC SECTION.
    INTERFACES zif_customer_credit.
ENDCLASS.

CLASS zcl_customer_credit IMPLEMENTATION.
  METHOD zif_customer_credit~get_credit.
    " El acceso al legacy queda AISLADO tras esta firma.
    " Hoy via una remote API / RFC liberado; manana lo que sea.
    DATA(lo_legacy) = NEW zcl_legacy_credit_facade( ).
    rs_credit = VALUE #(
      customer     = iv_customer
      credit_limit = lo_legacy->read_limit( iv_customer ) ).
  ENDMETHOD.
ENDCLASS.

Fíjate en lo que NO hay en la capa nueva: ni un SELECT a una tabla clásica, ni un CALL FUNCTION a un módulo no liberado. Todo eso vive detrás de zcl_legacy_credit_facade, en un solo punto.

Las reglas que hacen que esto funcione

• Una sola puerta. El legacy se toca en un único lugar por dominio. Si aparece un segundo sitio, el wrapper ha fallado.
• Tipos de tu dominio en la firma, no estructuras del legacy. La interfaz no debe delatar lo que hay detrás.
• Los errores se traducen. Un sy-subrc o un mensaje técnico del legacy se convierten en el error de tu dominio antes de cruzar la frontera.
• El wrapper es desechable a propósito. Su valor está en poder tirarlo el día que exista la released API sin tocar a sus consumidores.

Lo que ganas

Con esta capa, la migración deja de ser un big bang y se vuelve incremental: reescribes el interior de un wrapper cuando toca, no cuando el proyecto entero lo exige. Tu capa cloud nace limpia desde el día uno, aunque por debajo siga latiendo veinte años de ABAP clásico. Eso es, en la práctica, como se hace Clean Core en un sistema que no empezó limpio.

Con esto cerramos la serie de ABAP Cloud: del modelo de extensibilidad a la comprobación de release, del SQL restringido a la convivencia con el legacy. El hilo común es siempre el mismo: extiende por contratos, no por acoplamiento.