Destinations (SAP BTP)

Una aplicación solicita una destination por su nombre y recibe todo lo que necesita para hacer la llamada:

1. Un administrador crea la destination, por ejemplo S4_ALDER, en la subcuenta o en una instancia del Destination service.
2. La aplicación, vinculada a una instancia del Destination service, solicita S4_ALDER en tiempo de ejecución.
3. El Destination service busca primero en las destinations de esa instancia de servicio y, si no encuentra ninguna, en la subcuenta.
4. El servicio devuelve la configuración y, para muchos tipos de autenticación, los tokens que necesita la llamada.
5. Con el tipo de proxy OnPremise, la llamada pasa por el Connectivity service y SAP Cloud Connector; con el tipo de proxy Internet, sale directamente.

Como la aplicación solo conoce el nombre, pasar de pruebas a producción significa cambiar la destination, no el código. Las destinations de SAP BTP convierten los detalles de conexión en configuración de la que se encargan los equipos de operaciones.

Las propiedades adicionales que necesita una destination dependen de la herramienta consumidora y del escenario; SAP Business Application Studio, por ejemplo, solo muestra una destination cuando WebIDEEnabled está definido, y WebIDEUsage le indica para qué sirve la destination. Por tanto, una destination de SAP BTP es un pequeño contrato entre la plataforma y cada herramienta consumidora.

Puntos fuertes

• Credenciales fuera del código: los secretos y certificados permanecen en la plataforma, y el cockpit puede comprobar la conexión.
• Un único patrón para muchos destinos: las API de internet, los sistemas on-premise y las instancias de servicio de SAP BTP usan el mismo objeto.
• Opciones de identidad: principal propagation y los flujos OAuth permiten que el back-end vea al usuario real en lugar de una cuenta compartida.

Dónde están sus límites

• Configuración, no integración. Una destination no mapea datos, no reintenta llamadas ni supervisa el flujo de mensajes.
• Por subcuenta. Cada subcuenta necesita sus propias destinations. El cockpit puede exportar una destination a un archivo e importarla en otro lugar, y el descriptor MTA o la API REST del Destination service pueden crearlas, pero los landscapes con muchas subcuentas siguen multiplicando el mantenimiento.
• Los permisos del back-end siguen aplicándose. Una destination que funciona demuestra la conectividad, no que el usuario pueda ejecutar el servicio.

Las destinations de SAP BTP estandarizan cómo se conectan las aplicaciones, mientras que la autorización y la lógica de proceso residen en otro lugar.

1. Usar el nombre de host real para destinos on-premise. La URL debe contener el host virtual y el puerto definidos en SAP Cloud Connector, exactamente como están mapeados.
2. Olvidar el location ID. Con varios conectores en la subcuenta, una destination sin el location ID correcto va a la red equivocada.
3. Nombres ocultos. Una destination en una instancia de servicio con el mismo nombre que una destination de la subcuenta gana la búsqueda, lo que confunde a quien edita solo la copia de la subcuenta.
4. Usuarios técnicos en todas partes. La autenticación básica con un único usuario compartido oculta quién hizo qué en el back-end; principal propagation u OAuth basado en el usuario conservan la pista de auditoría.
5. Copiar propiedades a ciegas. Indicadores como HTML5.DynamicDestination amplían el acceso a cualquier usuario que haya iniciado sesión y solo deben definirse cuando un escenario los necesite.

La mayoría de las incidencias con destinations se deben a una discrepancia de nombres o de mapeo que la comprobación de conexión habría puesto de manifiesto.