Ponderar el impacto en el rendimiento
Power BI puede conectarse a los servicios web que ha publicado Business Central. Estos servicios web se basan en objetos de consulta o página. La principal diferencia entre un servicio web de página y un servicio web de consulta es:
Página
Puede usar una tabla de origen
Puede contener lógica de AL y columnas calculadas
Puede contener campos de flujo
Se almacena en caché en el nivel de servicio
Exécute toujours une instruction SELECT * sur la table source sous-jacente, indépendamment des colonnes définies dans l’objet de page
Consulta
Puede unir varias tablas de origen
Puede calcular agregaciones
No puede contener lógica de AL ni columnas calculadas
Puede contener campos de flujo
No se almacena en caché en el nivel de servicio
Ejecute la instrucción SELECT únicamente en las columnas que se hayan definido como columnas en el objeto de consulta
Consulta API
Puede unir múltiples tablas de origen (más rápido que la página API)
Puede calcular agregaciones
No puede contener lógica de AL ni columnas calculadas
Puede contener campos de flujo
No se almacena en caché en el nivel de servicio
Ejecute la instrucción SELECT únicamente en las columnas que se hayan definido como columnas en el objeto de consulta
No es necesario que se publique en la tabla Servicios web
Como puede que ya haya notado, el rendimiento de los objetos de consulta suele ser mejor que el de los objetos de página. Por eso recomendamos crear o usar objetos de consulta como orígenes de datos para Power BI. Incluso cuando necesita columnas calculadas, es algo que también puede definir en Power BI Desktop. Hágalo creando columnas o medidas calculadas después de importar los datos. Se recomienda utilizar solo objetos de página como conjuntos de datos para Power BI si necesita un determinado cálculo o ejecución de la lógica empresarial utilizando el código AL, ya que eso no se puede realizar en Power BI Desktop después de importar los datos.
Extracciones eficientes a lagos de datos o almacenes de datos
Al establecer un lago de datos o un almacén de datos, normalmente hay que hacer dos tipos de extracción de datos:
Una carga histórica (todos los datos de un momento determinado)
Cargas delta (lo que ha cambiado desde la carga histórica)
La forma más rápida y menos problemática de obtener una carga histórica de Business Central Online es exportar una base de datos como archivo BACPAC (usando el centro de administración de Business Central) y restaurarla en una Azure SQL Database o un SQL Server. Para las instalaciones locales, solo puede hacer una copia de seguridad de la base de datos de inquilinos.
La forma más rápida y menos problemática de obtener cargas delta de Business Central Online es establecer consultas de API configuradas con escalado horizontal de lectura y usar el campo de auditoría de datos LastModifiedOn (introducido en la versión 17.0) en los filtros.
Desarrollar servicios web eficientes
Business Central admite servicios web para facilitar la integración con sistemas externos. Como desarrollador, debe pensar en el rendimiento de los servicios web tanto para el servidor de Business Central (el punto de conexión) como para el consumidor (el cliente).
Evite el uso de páginas de IU estándares para exponerlas como puntos de conexión de servicios web. Muchos elementos, como los cuadros informativos, no se exponen en OData, pero usan recursos de computación.
Algunos de los elementos que han solido causar problemas de rendimiento en páginas expuestas como puntos de conexión son:
Lógica pesada en OnAfterGetCurrRecord
Muchos campos SIFT
Cuadros informativos
Uso de escalado horizontal de lectura
Business Central es compatible con la función de Escalamiento horizontal de lectura en Azure SQL Database y SQL Server. El escalado horizontal de lectura se utiliza para equilibrar la carga de las cargas de trabajo analíticas en la base de datos que solo lee datos. El escalado horizontal de lectura está integrado como parte de Business Central Online, pero también se puede habilitar para versiones locales.
El escalado horizontal de lectura se aplica a consultas, informes o páginas de API. Con estos objetos, en lugar de compartir el principal, se pueden configurar para que se ejecuten en una réplica de solo lectura. Esta configuración esencialmente los aísla de la carga de trabajo principal de lectura y escritura para que no afecten al rendimiento de los procesos empresariales.
Como desarrollador, puede controlar el escalado horizontal de lectura en los informes, las páginas de API y los objetos de consulta mediante la propiedad DataAccessControl.
La propiedad DataAccessIntent establece si los datos del objeto se deben obtener de una réplica de solo lectura de la base de datos o de la base de datos principal.
La propiedad tiene los siguientes valores:
ReadOnly: especifica que se deben obtener los datos de una réplica de solo lectura.
ReadWrite: especifica que se deben obtener los datos de la base de datos principal. ReadWrite es el valor predeterminado.
Para los informes, las páginas de API y las consultas, el servidor de Business Central puede usar réplicas de bases de datos de solo lectura en Azure SQL Database y SQL Server. Si las réplicas están habilitadas, use esta propiedad para reducir la carga en la base de datos principal.
El uso de ReadOnly también podría mejorar el rendimiento al visualizar objetos. ReadOnly funciona como una sugerencia para que el servidor dirija la conexión a una réplica secundaria (solo lectura), si hay alguna disponible. Cuando se ejecuta una carga de trabajo en la réplica, las operaciones de inserción/eliminación/modificación no son posibles. Si alguna de estas operaciones se ejecuta en la réplica, se lanza una excepción en tiempo de ejecución.
Desde el cliente, el valor de la propiedad se puede sobrescribir usando la página 9880 Lista de intenciones de acceso a la base de datos.
Consejos de rendimiento para trabajar con Power BI y Business Central
Teniendo en cuenta la información anterior, probablemente entienda que es importante controlar el rendimiento, especialmente al crear informes de Power BI en Business Central. A continuación enumeramos algunas cosas que hay que tener en cuenta.
Es mejor crear una nueva consulta o una nueva página y utilizarla como origen de datos dedicado para Power BI en lugar de utilizar páginas o consultas existentes que también sirven para otros fines. Al adaptar su conjunto de datos (página/consulta) para su informe de Power BI específico, solo tiene que incluir los campos que necesita, nada más.
En una situación en la que pueda elegir, debe priorizar las consultas sobre las páginas como orígenes de datos para Power BI. Los objetos de consulta generan una declaración de selección mejor y más rápida en la base de datos SQL y los objetos de consulta también pueden agregar datos. Debe crear las consultas para que solo devuelvan los datos que sean necesarios para el informe de Power BI, nada más. Por ejemplo, si el informe requiere datos de ventas por día, cree un objeto de consulta en el que obtenga los datos de ventas y los agregue por día. En lugar de obtener varios registros para un día en particular y dejar que Power BI agregue los registros después de la importación.
Implementar filtros en consultas y páginas. Si hay registros en las tablas de origen subyacentes que no sean obligatorios en su informe, debe filtrarlos lo antes posible.
No incluya campos ni columnas que no sean obligatorios en su conjunto de datos. Siempre puede agregarlos más tarde, cuando sea necesario, y el servicio web se actualizará automáticamente.
Si necesita información de las tablas de movimientos, asegúrese de agregar los registros. Las tablas de movimientos contienen muchos registros y, normalmente, no dejan de crecer. Es muy poco probable que necesite importar y visualizar cada movimiento contable individual en un informe de Power BI. Por tanto, cree la consulta con el nivel de agregación que coincida con los requisitos del informe.
Como recomendación, yo le sugiero usar objetos de consulta en lugar de objetos de página. Esto se debe a que los objetos de consulta suelen generar instrucciones SQL más rápidas, pueden unir varias tablas y agregar datos.
Los objetos de página le permiten calcular campos utilizando el lenguaje de programación AL, mientras que los objetos de consulta no pueden hacerlo. Sin embargo, Power BI también puede crear columnas y medidas calculadas utilizando el lenguaje DAX. Así, en lugar de crear un objeto de página con cálculos complejos en código AL, probablemente sea mejor crear un objeto de consulta y dejar que Power BI realice los cálculos complejos tras importar los datos.