Configuración del acceso a una API de SAP SuccessFactors en SAP Build Apps
By s4pcademy
En esta publicación de blog, compartiré la configuración requerida para evitar el uso compartido de recursos de origen cruzado (CORS) al comunicarme desde SAP Build Apps con una API de SAP SuccessFactors.
Mi colega Alejandro Rodríguez Barea se me acercó para preguntarme cómo podemos hacer que la comunicación entre SAP Build Apps y SAP SuccessFactors, dado que él está creando una aplicación usando los datos en SAP SuccessFactors pero se enfrentaba a la infame CORS problema al llamar a la API desde SAP Build Apps. Compartiré aquí los problemas enfrentados y cómo podemos resolverlos.
Estamos interesados en la información personal, que se expone a través de las API de SAP SuccessFactors Employee Central. En API Business Hub, hay un paquete de API que contiene todos los Central de empleados de SAP SuccessFactors APIs, dentro de ella encontramos la API de información personalque contiene la entidad PerPersonal que usaré en esta publicación de blog.
Entidad PerPersonal en la Central de empleados de SSFF: API de información personal
Alejandro compartió conmigo las credenciales necesarias para conectarse a la API de SAP SuccessFactors. Los configuré en SAP API Business Hub para validarlos e interactuar rápidamente con el sistema en vivo y tener una idea de los datos expuestos.
Puede encontrar la lista de servidores API de SAP SuccessFactors aquí: https://help.sap.com/docs/SAP_SUCCESSFACTORS_PLATFORM/d599f15995d348a1b45ba5603e2aba9b/af2b8d5437494b12be88fe374eba75b6.html?locale=en-US
En caso de que se pregunte por qué no recibimos un error de CORS cuando llamamos a la API desde SAP API Business Hub, pero sí lo recibimos de SAP Build Apps…. Al llamar a la API desde SAP API Business Hub, la llamada no se realiza directamente desde su navegador web, sino que se envía a un servidor que es el que llama a la API en su nombre. Lo que significa que la llamada a la API de SAP SuccessFactors en realidad se realiza desde un servidor y no desde el navegador web. Al contrario de cómo se realiza la llamada desde SAP Build Apps, que se realiza desde su navegador web.
Para analizar lo que sucedía al llamar a la API, me basé en gran medida en las herramientas de desarrollo web disponibles en mi navegador web (Mozilla Firefox en caso de que se lo pregunte 🙂 ya que algunos de los errores que se muestran en la interfaz de usuario web resumieron un poco el error real bajo el Además, utilicé un cliente REST… en mi caso, Postman.
¿Qué pasa si llamamos a la API directamente desde SAP Build Apps?
Para probar esto, configure un Integración REST directa en SAP Build Apps, configure la URL base, por ejemplo, https://apisalesdemo2.successfactors.eu/odata/v2, en GET Collection configure una entidad, por ejemplo ¿Personal?$top=20, incluir nuestras credenciales como un encabezado HTTP, por ejemplo Autorización: Básica c2ZhZG1yMDIx, y luego haga clic en el botón Ejecutar prueba.
- Error en la interfaz de usuario: Error: TypeError: no se pudo recuperar. ¿El servidor permite CORS? Estado: indefinido.
- Error en la consola del navegador: Acceso para buscar en ‘https://apisalesdemo2.successfactors.eu/odata/v2/PerPersonal?$top=20’ desde el origen ‘https://emea-south-sapbuild-cmte91cp.design-time.eu10.apps.build .cloud.sap’ ha sido bloqueado por la política de CORS: no hay ningún encabezado ‘Access-Control-Allow-Origin’ en el recurso solicitado. Si una respuesta opaca satisface sus necesidades, establezca el modo de solicitud en ‘sin cors’ para obtener el recurso con CORS deshabilitado.
Desafortunadamente, no podemos establecer el modo de solicitud en sin corazones en SAP Construir aplicaciones. Además, espera que haya una Acceso-Control-Permitir-Origen encabezado y si probamos la llamada desde un cliente REST, por ejemplo, Postman, no se devuelve dicho encabezado.
En Web Developer Tools, puedo ver que se están realizando dos llamadas, una con el método GET y la segunda con el método OPTIONS. El método OPTIONS devolvía un error 401, lo que significa que no estoy autorizado para realizar la llamada. Validé esto haciendo la misma llamada desde Postman y el método OPTIONS requiere autenticación.
Ok, entonces encontré dos formas de resolver este problema… Discutiré ambos enfoques en esta publicación de blog:
- Uso de destinos SAP BTP
- Uso de la gestión de API de SAP
1. Uso del destino BTP de SAP
Solo me topé con esto después de agregar un destino SAP BTP a SAP Build Apps y honestamente lo encontré por error.
Configurar el destino de SAP SuccessFactors en SAP BTP
A continuación, se muestra el destino que configuré en la subcuenta SAP BTP. La URL que configuré es https://[my-api-server].successfactors.eu/odata/v2/. Observe la propiedad AppgyverEnabled que se agregó al destino y también que los detalles básicos de autenticación son parte del destino.
Destino SAP SuccessFactors en SAP BTP
Crear el destino de SAP SuccessFactors en SAP BTP
En SAP Build Apps, podemos agregar un sistema SAP y seleccionar el destino. En mi caso, SFSF_Demo. Procedí a «instalarlo» y aparece el siguiente mensaje. Aunque no se encuentran entidades de datos en ese destino en particular. ⚠️ Que no te engañe el mensaje de no entidades de datos.
No hay entidades de datos en el sistema SAP
Aunque no hay entidades de datos en ese punto final en particular, es posible configurar una configurándola manualmente al crear una entidad de datos utilizando una integración de API REST de destino BTP de SAP. Para hacer esto, vaya a Entidades de datos clásicas de SAP Build Apps > botón Crear entidad de datos > Integración de API REST de destino BTP de SAP. Luego, puede seleccionar el destino que instalamos previamente (SFSF_Demo) y configurar la entidad de datos manualmente. El siguiente video muestra cómo puede instalar el sistema SAP, agregar la entidad de datos, establecer el esquema de la respuesta y guardar la nueva entidad de datos.
¿Simple verdad? Me gusta este enfoque debido a su simplicidad.
2. Configuración de la gestión de API de SAP
lo sé que otros en el pasado he usado SAP API Management para sortear CORS, así que haré exactamente eso. Similar a lo que se mencionó anteriormente con respecto a la llamada de SAP API Business Hub… cuando la llamada se realiza a través de SAP API Management, la llamada a la API se realiza desde el servidor: API Management, no el navegador.
Como todos sabemos, podemos importar fácilmente las API disponibles en SAP API Business Hub desde SAP API Management. Busco el paquete SAP SuccessFactors Employee Central y copio la API de información personal a mi arrendatario.
Copie la API de información personal de SAP SuccessFactors EmployeeCentral
Luego configuro el servidor API y establezco su nombre y título. Realice los cambios en el alias del host, la ruta base de la API, si corresponde, y haga clic en Aceptar.
Copiar detalles de la API
Una vez creado, procedí a implementar la API que me da una nueva URL. Ahora puedo llamar a la API de SAP SuccessFactors a través de esta URL.
¿Qué pasa si configuramos esta nueva URL en SAP Build Apps y la probamos? ¿Funcionará?
Desafortunadamente, obtenemos el mismo error que antes.
Ok, entonces vi un entrada en el blog de mi colega Murali Shanmugham, donde estableció una regla de ruta en la pestaña Proxy Endpoint de la API. Además, edita los flujos PreFlow y PostFlow en PolicyEditor.
Voy a hacer algo un poco diferente aquí… Sé que ahora hay un Plantilla de política para CORS disponible en SAP API Business Hub y lo usaré para los flujos de políticas de API.
Plantilla de política CORS en SAP API Management Discovery
Recursos en la plantilla de política de CORS
Ok, al aplicar la plantilla de políticas podemos ver que tiene asignadas un par de políticas:
- en ProxyEndpoint > PreFlow – Incoming Request, la política handleoptions, que se llevará a cabo luego de que request.verb sea OPTIONS. Establece los diferentes encabezados necesarios.
- en ProxyEndpoint > PostFlow – Solicitud saliente la política setCORS, que insertará algunos parámetros de encabezado en los encabezados de respuesta.
¿Qué pasa si volvemos a probar desde SAP Build Apps después de aplicar la plantilla de política CORS?
En la interfaz de usuario vemos el mismo error. “Error: TypeError: no se pudo recuperar. ¿El servidor permite CORS? Estado: indefinido” pero vemos una historia diferente en la consola del navegador. Podemos ver que la llamada OPTIONS fue exitosa y que la solicitud GET ahora tiene un error diferente.
Acceso para buscar en ‘https://dev-advocates-free-tier.test.apimanagement.eu10.hana.ondemand.com/sfsf/odata/v2/PerPersonal?$top=20’ desde el origen ‘https://emea -south-sapbuild-cmte91cp.design-time.eu10.apps.build.cloud.sap’ ha sido bloqueado por la política de CORS: la autorización del campo de encabezado de solicitud no está permitida por Access-Control-Allow-Headers en la respuesta de verificación previa.
Se parece al error anterior, pero si miramos de cerca podemos ver que indica que el el encabezado de autorización no está permitido en Access-Control-Allow-Headers. Este es el encabezado de Autorización que estamos pasando en nuestra solicitud. Tenga en cuenta que el error menciona la respuesta de verificación previa. Lo que significa que tenemos que incluir el autorización encabezado en Acceso-Control-Permitir-Encabezados cuando manejamos opciones. Incluyo el nombre del encabezado en el opciones de mango política y vuelva a implementar la API.
Incluir el encabezado de autorización en la respuesta de verificación previa del encabezado Access-Control-Allow-Headers
¿Qué pasa si volvemos a probar desde SAP Build Apps después de incluir el encabezado de Autorización?
Envía una nueva solicitud desde SAP Build Apps y ahora recibimos un nuevo error… Error: SyntaxError: Token inesperado ‘<', “.
Aunque obtenemos un error, ¡esto es genial! Parece que hemos resuelto el problema relacionado con CORS, pero nuestra respuesta parece un documento XML. Especifiquemos en nuestra solicitud que esperamos que el cuerpo de la respuesta sea una carga JSON. Podemos hacer esto especificando un Aceptar: aplicación/json Encabezado HTTP. Además, establecí la ruta de la clave de respuesta porque conozco la estructura de la carga útil de JSON.
Incluido el encabezado HTTP de aceptación y la ruta de la clave de respuesta
Si volvemos a probar obtendremos un resultado exitoso!!!! Ahora podemos configurar nuestro esquema en función de la respuesta y guardar nuestra entidad de datos.
Gracias por leer hasta aquí…. hemos cubierto mucho en esta publicación de blog. Hemos visto cómo podemos usar el destino SAP BTP para comunicarnos directamente con el sistema SAP SuccessFactors, sin necesidad de que otro sistema/proxy esté en el medio y no tenemos que lidiar con CORS. Dicho esto, también vimos cómo podemos aprovechar SAP API Management para solucionar el problema de CORS y cómo podemos resolver diferentes problemas, por ejemplo, el encabezado de autorización. Espero que esta publicación de blog lo ayude a solucionar problemas relacionados con CORS + SAP Build Apps + políticas en SAP API Management.
Ahora, a Alejandro Rodríguez Barea quien le mostrará la genial aplicación que creó con la API de SAP SuccessFactors.
