Service Binding (RAP)

Un service binding es el último paso de la cadena RAP que va del modelo de datos al servicio consumible:

1. Las CDS view entities y una behavior definition forman el business object.
2. Las projection views dan forma a lo que necesita un servicio concreto.
3. Una service definition enumera las entidades que expone el servicio.
4. El service binding decide cómo se expone ese alcance: qué protocolo, qué tipo de consumo y qué versión.

Sus parámetros son el nombre del servicio, idéntico al nombre del binding; el tipo de binding; la versión del servicio; y el estado de publicación. Como el protocolo y el alcance son objetos separados, varios bindings pueden apoyarse en una misma service definition: Alder Manufacturing podría exponer el mismo alcance de solicitudes de pedido una vez como servicio de UI OData V4 para su aplicación SAP Fiori y otra vez como Web API OData V4 para un portal de proveedores de Cedar Office Supply. Un service binding es, por tanto, el punto en el que un servicio RAP se convierte en un endpoint concreto y direccionable.

La documentación actual de SAP enumera cuatro protocolos y dos categorías de consumo:

La categoría importa tanto como el protocolo. Los servicios de UI incluyen en sus metadatos anotaciones de UI, ayudas de valores, side effects y feature control, y ofrecen la vista previa de SAP Fiori elements. Las Web API no contienen información específica de UI, están pensadas para consumidores desconocidos y pueden ampliarse. SAP recomienda OData V4 siempre que sea posible para los servicios transaccionales, y señala que la compatibilidad completa de SAP Fiori elements con OData V4 solo se garantiza en escenarios habilitados para draft. Compruebe qué tipos de binding ofrece su release en su documentación de RAP. Criterio de decisión: vincule como UI cuando una aplicación SAP Fiori consuma el servicio, y como Web API en todos los demás casos.

• Publicación: el binding debe estar activo, y el botón Publish del editor de service bindings ejecuta las listas de tareas que habilitan el endpoint. SAP subraya que la publicación habilita el servicio solo en el sistema actual; no hace que el servicio sea accesible desde otros sistemas.
• Después del transporte (on-premise y Private Edition): SAP documenta que el service binding solo habilita el servicio localmente en el sistema de desarrollo; en los sistemas de calidad y de producción, el servicio se activa con las herramientas de Gateway, los servicios OData V4 como grupos de servicios en /IWFND/V4_ADMIN y los servicios OData V2 en /IWFND/MAINT_SERVICE.
• ABAP environment (SAP BTP y extensibilidad para desarrolladores de Public Edition): una Web API llega a los llamantes externos a través del inbound service generado por el binding, añadido a un communication scenario publicado, y después a un communication arrangement que crea un administrador.
• Versionado: añadir otra service definition a un binding existente crea la siguiente versión del servicio, de modo que los cambios llegan a los nuevos consumidores sin romper los existentes.

Un service binding publicado es un endpoint local; la exposición a otros sistemas es un paso de configuración separado.

1. Vincular una aplicación SAP Fiori a una Web API. La aplicación se carga pero muestra tablas vacías o diseños predeterminados, porque los metadatos de una Web API no contienen anotaciones de UI. Cree un binding UI.
2. Elegir OData V4 para una aplicación transaccional sin draft. La compatibilidad de SAP Fiori elements con V4 solo es completa con draft; habilite el draft o prevea carencias.
3. Modificar en el mismo lugar un servicio ya liberado. Los consumidores fallan sin aviso. Añada en su lugar una versión del servicio.
4. Suponer que Publish significa accesible. Un llamante remoto sigue necesitando la configuración de comunicación, y en on-premise los usuarios necesitan autorizaciones para el servicio.
5. Depurar primero la UI. Cuando falla una vista previa, compruebe que el binding está activo y publicado antes de tocar las anotaciones.

La mayoría de los problemas con los service bindings provienen de elegir la categoría equivocada o de omitir un paso de publicación, no del business object que hay detrás.