Thumbnail image

Importación de datos low‑code personalizada en Finance and Operations apps

!
Atención: Este artículo se publicó hace más de 365 días. La información podría estar desactualizada.
Advertencia
Este artículo ha sido traducido automáticamente con Copilot y todavía está pendiente de revisión manual. Ante cualquier error por favor revise el original el inglés cambiando el idioma en la parte superior-derecha

Motivaciones

Las integraciones de datos son un requisito fundamental en las implementaciones de ERP en la nube y, históricamente en Dynamics, se han escrito en X++ procesos que leen datos, los procesan y finalmente los guardan en un formato que Dynamics entiende. Estos procesos ETL escritos a mano han sido (y siguen siendo) una fuente frecuente de problemas en cuanto a mantenibilidad, reutilización y, especialmente, rendimiento, ya que no siempre están diseñados para funcionar bien con grandes volúmenes de datos.

A medida que los clientes adoptan progresivamente soluciones low‑code/no‑code que son más fáciles de ampliar y requieren menos coste de mantenimiento, mostramos aquí un ejemplo de cómo una tarea típicamente intensiva en desarrollo puede abordarse como una personalización low‑code.

Exenciones

(1) El resultado final de este proof‑of‑concept fue un esfuerzo de equipo. Ainhoa Menoyo creó el flujo en Power Automate. Damien Bird aportó la idea de la Azure Function. Yo me encargué de afinar y ensamblar los componentes hasta conseguir el flujo end‑to‑end descrito en este artículo. Te animo a involucrar a tus equipos de desarrollo para sacar el máximo partido a todas las tecnologías al abordar requisitos y personalizaciones en Finance and Operations.

(2) Deliberadamente no entro en todos los detalles técnicos: creo que lo interesante es seguir el razonamiento que te permite abordar tus propios requisitos con estrategias similares. Los detalles técnicos están bien documentados en la documentación oficial.

El caso

El caso que intentábamos resolver es sencillo por separado, pero es una tarea que se repite en cada proyecto, a menudo duplicando código y generando cargas pesadas en clases X++ específicas que son difíciles de escalar para grandes volúmenes. La idea es: un tercero coloca ficheros en algún sitio (en este caso en Blob Storage, pero puede ser cualquier ubicación accesible por Power Automate) y queremos importar el contenido de esos ficheros en F&O.

Lo primero que se nos ocurre es usar el Data Management Framework (DMF) en Finance and Operations, con su Recurring integrations API que permite encolar jobs de importación desde aplicaciones externas. Esto es estándar, sin necesidad de personalización.

La parte compleja es que puede que queramos usar data packages para importar directamente a entidades de datos, lo cual reduce personalizaciones. Entonces necesitamos crear los data packages “manualmente” en Power Automate para construir un fichero que Finance and Operations importará usando solo funcionalidades estándar.

El formato de un data package es un fichero comprimido que contiene un package manifest, un package header y los ficheros correspondientes a las entidades de datos incluidas. Puedes crear un data package generando un job DMF y exportando datos. Lo que hicimos aquí fue obtener el package header y el manifest desde ese paquete auto‑generado y subirlos a un lugar accesible por Power Automate (en este caso, la misma cuenta de storage donde se dejarán los ficheros). Tras estos pasos de preparación, Power Automate tiene todos los componentes para crear nuevos data packages por sí mismo.

Un detalle pequeño pero importante: necesitamos crear un ZIP con varios ficheros para construir el data package, y hasta la fecha Power Automate no realiza esa operación de forma nativa. Usamos una Azure Function escrita en C# para realizar este paso (esta es la parte low‑code). Esta función puede reutilizarse en múltiples integraciones que requieran crear ZIPs.

Luego la solución global queda así:

La solución

La parte de Finance and Operations (todo estándar)

Los componentes de Finance and Operations implicados son tareas DMF estándar. Para simplificar usamos una entidad de datos estándar, pero cualquier entidad servirá.

  • Crea un proyecto DMF con las entidades necesarias y exporta un data package.
  • Sube los ficheros de header y manifest al storage que prefieras.
  • Crea un proyecto DMF de Import, con la misma entidad del paquete exportado.
  • Configura un job de integración recurrente.
  • Se requiere un Application ID registrado en tu dominio Entra para que el job funcione; prepáralo con antelación.
  • Guarda el ID del job para usarlo más tarde.

Más información:

La Azure Function (la parte ‘low code’)

Poco que decir: es una función que recibe un objeto serializado, lo deserializa para obtener los bytes originales y guarda esos bytes en un fichero Zip. La función es agnóstica y puede usarse en otros escenarios; quizá alguien proponga una implementación mejor, pero hace su trabajo.

Más información:

La parte Power Automate (la parte ‘no code’)

Aquí ocurre la mayoría de la lógica. El flujo se divide en 3 secciones:

La primera obtiene secretos desde Azure Key Vault. Puedes almacenar estos datos de otra forma, pero evita secretos en texto plano. Es preferible guardar las credenciales en un Vault.

Estos son los valores que necesitarás (pueden variar según tu implementación):

  • F&O base Uri
  • Azure Function Uri
  • Para el job DMF recurrente:
    • Application ID
  • Para la autenticación de la API DMF:
    • Tenant ID
    • Client ID
    • Client Secret

La segunda sección lee el fichero a importar y los ficheros necesarios para construir el data package, los serializa (Compose y encode), llama a la Azure Function y guarda el ZIP en la cuenta de storage (estos pasos son opcionales, sirven para probar el flujo y como ejemplo).

Y el último paso es encolar el job de importación en F&O usando la API de recurring integrations con una acción HTTP POST. Aquí se usan los valores del Vault para la autenticación OAuth:

Conclusión

Como decía en la introducción, la parte técnica de esta solución no es excepcional, pero muestra la aproximación de intentar cumplir requisitos de negocio sin entrar directamente en modo desarrollo y pensar si existen formas de lograr el mismo resultado con soluciones más fáciles de mantener.

Publicaciones similares