BAPI

Una BAPI conecta una definición orientada a objetos con una implementación clásica:

1. En el Business Object Repository, un tipo de business object, como un pedido de compra, declara métodos como crear, modificar u obtener detalle. Cada uno de estos métodos de API es una BAPI.
2. Detrás de cada método hay un módulo de funciones habilitado para RFC, de modo que la BAPI puede llamarse dentro del sistema o de forma remota mediante RFC.
3. Quien llama pasa parámetros de importación y tablas; la BAPI informa del éxito o de los errores en un parámetro de retorno tipado con la estructura BAPIRET2, en lugar de lanzar excepciones.
4. Las BAPI de modificación siguen un modelo transaccional en el que la propia BAPI no hace commit. Quien llama decide cuándo guardar, normalmente llamando a BAPI_TRANSACTION_COMMIT después de una o varias llamadas a BAPI, o a su contraparte de rollback tras un error.

El BAPI Explorer, que se inicia con la transacción BAPI, permite navegar por los tipos de business object y sus BAPI por componente de aplicación, y muestra los parámetros y la documentación. Una BAPI es, por tanto, un contrato de nivel de negocio sobre un módulo de funciones, con el commit a cargo de quien llama.

Las BAPI son anteriores a SAP Fiori y a OData, pero siguen formando parte de muchos entornos:

• Integraciones punto a punto y de middleware que llaman a SAP ERP o SAP S/4HANA mediante RFC, por ejemplo para crear pedidos de cliente desde una tienda web.
• Programas de migración de datos y de procesamiento masivo que contabilizan documentos con las mismas comprobaciones que las transacciones de diálogo.
• Servicios OData construidos sobre BAPI. En on-premise, los proyectos de SAP Gateway suelen asignar las operaciones de una entidad a BAPI existentes mediante la importación RFC/BOR del Service Builder, y SAP documenta un patrón RAP que llama a una BAPI dentro de un business object RAP a través de una clase wrapper.

En Alder Manufacturing, un portal de proveedores que crea pedidos de compra para Cedar Office Supply puede seguir contabilizando mediante una BAPI de pedidos de compra envuelta en una API más reciente. Las BAPI sobreviven a menudo como el motor bajo una interfaz moderna, más que como la interfaz misma.

SAP clasifica las BAPI como API clásicas. No son API liberadas en el sentido de ABAP Cloud, por lo que el código escrito en la versión de lenguaje ABAP for Cloud Development no puede llamarlas directamente.

SAP publica una lista de API clásicas para Private Edition y remite a los desarrolladores al BAPI Explorer para estudiarlas. Los informes de clean core contabilizan las referencias a API clásicas de la lista por separado de las API liberadas. Una BAPI se tolera, por tanto, como puente en un entorno clean core, pero no se trata como la interfaz de destino.

1. Olvidar el commit. La llamada termina sin errores pero no se guarda nada, porque quien llama nunca ejecutó BAPI_TRANSACTION_COMMIT.
2. Ignorar la tabla de retorno. Las BAPI informan de los errores como mensajes en el parámetro de retorno; un programa que solo comprueba excepciones no contabiliza nada e informa de éxito.
3. Confundir las etiquetas de "liberado". El BAPI Explorer muestra las BAPI liberadas en el Business Object Repository, lo que no equivale a una API liberada bajo un contrato de liberación de ABAP Cloud.
4. Envolver sin un responsable. Un wrapper C1 alrededor de una BAPI necesita un responsable que lo sustituya cuando SAP libere una API sucesora.

La mayoría de los defectos de las BAPI provienen del modelo transaccional y del tratamiento de mensajes, no de la lógica de negocio que contiene la BAPI.