Desde hace ya tiempo no es posible integrarse con los servicios publicados desde un entorno Business Central SaaS mediante Autenticación Básica. Desde la “Business Central 2022 release wave 1” ya no tenemos la opción de configurar la clave autenticación básica en la ficha de usuario, tal y como se podría hacer para un entorno on-premise.
Tabla de contenidos
Error acceso a Business Central
Al invocar el servicio desde el navegador con las credenciales de usuario acceso a Business Central obtenemos el siguiente error.
Por suerte, para este escenario, existe ya bastante documentación para configurar credenciales de acceso OAuth 2.0 utilizando Azure AD desde Azure portal.
El objetivo de esto es proporcionar todas las herramientas necesarias para poder lanzar pruebas de integración a servicios de Business Central en SaaS desde cualquier sistema. Para poder reproducir el escenario planteado en este tutorial es necesario disponer de:
- Entorno SaaS de Business Central (sandbox) en Azure.
- Acceso con privilegios de administrador en Azure portal.
- Herramienta colaborativa Postman.
- Entorno SQL Server por ejemplo (SQL Server 2022 Developer)
- SQL Management Studio
- Credenciales para obtener el Token y lanzar las peticiones a servicios Business Central.
- Id. de aplicación (cliente), Id. de directorio (inquilino o “tenant” que identifica al sandbox)
- Certificados y secretos Valor
Una vez seguidos los pasos de la documentación de los enlaces adjuntos, podemos encontrar “Id. de aplicación (cliente)” y “Id. de directorio (inquilino)” en Información general de la aplicación registrada en Azure portal. Además, también encontraremos el valor del “secreto de cliente” en la sección Certificados y secretos de la misma aplicación.
En este punto, la configuración de la aplicación en Business Central desde el buscador Atl+Q ahora deberá realizarse desde “Aplicaciones de Microsoft Entra”.
Azure portal
Para facilitar las indicaciones con las credenciales obtenidas de Azure portal de aquí en adelante en este documento nos vamos a referir a estas de la siguiente forma.
- Id. de aplicación (cliente) –> {Idappcli}
- Id. de directorio (inquilino) –> {Idtenant}
- Certificados y secretos Valor –> {Secreto}
Paso 1: Montar la petición
El primer paso que vamos a realizar, será montar la petición OAuth 2.0 para poder lanzar pruebas desde Postman y tener -así- un ejemplo claro de referencia con petición y respuesta. Así pues, vamos a lanzar un ejemplo de petición contra la siguiente URL. Para ello, será necesario modificar las variables indicadas por los datos correspondientes {Idtenant} y {NombreSandbox}.
- En authorization type usaremos el OAuth 2.0.
- Add authorization data to Request Headers.
- Grant type → Client Credentials
- Access Token URL
- Client ID → {Idappcli} Id. de aplicación (cliente) obtenido de azure portal.
- Client Secret → {Secreto} Certificados y secretos obtenido de azure portal.
- Scope
- Client Authentication → Send client credentials in body
Una vez configurado todo según los pasos y lo mostrado en las pantallas obtendremos el token de acceso al pulsar “Get New Access Token”.
En cuanto al token que acabamos de obtener, se caracteriza por tener fecha de caducidad por defecto de una hora. De este modo, cuando caduque es necesario generar otro nuevo, de la misma forma, para poder lanzar nuevas peticiones de datos.
Una vez que ya se puede lanzar la petición, el token se añade como una cabecera más de “Authorization” en el request de la petición, algo imprescindible para el acceso al sistema.
Una vez realizado este paso, deberemos recibir un Status 200 y el cuerpo de la respuesta.
Además, en Postman, lo correcto es trabajar con variables, por ejemplo, para guardar el {Idappcli}, el {Secreto} o el nombre del sandbox. Para ello, tenemos que clicar en el botón derecho sobre la cadena de caracteres a definir como variable que luego se puede referenciar (tal y como se ve en las pantallas anteriores es el texto naranja entre corchetes).
Paso 2: Montar los scripts básicos en SQL Server
En este momento, lo primero que hay que hacer es activar, con el siguiente script, los procedimientos almacenados de sistema que vamos a utilizar.
Además, puedes entrar al repositorio público en github con los 2 scripts aquí.
Artículos relacionados:
- Finaliza el soporte de SQL Server 2017. ¡Actualízate a SQL Server 2019 y conoce todos los beneficios!
- Las empresas apuestan por Aitana para mantener el SQL Server y conseguir un rendimiento óptimo de su ERP
- Gestión de entornos Business Central SaaS
En primer lugar, montaremos la petición para obtener el token. Lo adecuado es montar un procedimiento almacenado en la base de datos con parámetros que podamos invocar desde cualquier script.
Al lanzar este script simple obtendremos la respuesta json con el token. En este momento debemos trabajar la response json para extraer el token y guardarlo en una tabla para, posteriormente, poder consultarlo.
Una vez que hemos realizado todo esto, obtendremos la respuesta del servicio con el token. En Postman nos informa directamente el valor del token y crea la cabecera correspondiente en la request.
Después, podremos lanzar el segundo script para consultar el servicio ya con el token. Lo idóneo será montar un procedimiento almacenado en la BD con parámetros que se puedan invocar desde cualquier script. En este caso, también será necesario trabajar la json response para extraer los datos que consideremos según los requerimientos de la tarea.
Una vez realizados estos pasos, obtendremos la respuesta del servicio igual que en el Postman.
Ya con la respuesta, tenemos todo lo necesario para empezar a desarrollar una integración desde una base de datos SQL Server hacia Business Central SaaS.
En este sentido, lo idóneo del programa es configurarlo para que al caducar el token se lance de nuevo el proceso de refresco para obtener un nuevo token. Por ejemplo, podríamos plantear que al recibir un status “401 No autorizado” cogeremos esa excepción y crearemos la petición de actualización del token. De esta forma, este proceso no detendrá la dinámica de trabajo.
Finalmente, para conseguir más seguridad en el proyecto es necesario que guardemos el {Secreto} en Azure Key Vault en lugar de exponerlo directamente en Postman o en nuestro sistema.
¿Te interesa? ¿Quieres más información? ¡No esperes más y contáctanos! Rellena este formulario y nuestros expertos se pondrán en contacto contigo.
David Frías
Operaciones VAL – BA
