Pesar o impacto sobre o desempenho
O Power BI pode de conectar aos serviços Web que o Business Central publicou. Esses serviços Web se baseiam na página ou nos objetos de consulta. A principal diferença entre uma página WebService e um WebService de consulta é:
Página
Pode usar uma tabela de origem
Pode conter a lógica AL e as colunas calculadas
Pode conter campos de fluxo
Em cache na camada de serviço
Sempre executa um SELECT * na tabela de origem subjacente, independente das colunas definidas no objeto da página
Consulta
Pode associar várias tabelas de origem
Pode calcular agregações
Não pode conter lógica AL ou colunas calculadas
Pode conter campos de fluxo
Não tem cache na camada de serviço
Seleciona apenas as colunas definidas como colunas no objeto de consulta
Consulta API
Pode associar várias tabelas de origem (mais rápido do que a página de API)
Pode calcular agregações
Não pode conter lógica AL ou colunas calculadas
Pode conter campos de fluxo
Não tem cache na camada de serviço
Seleciona apenas as colunas definidas como colunas no objeto de consulta
Não precisa ser publicado na tabela de serviços Web
Como você deve ter percebido, o desempenho de objetos de consulta geralmente é melhor do que o desempenho de objetos de página. Por isso, é recomendável criar ou usar objetos de consulta como fontes de dados para o Power BI. Mesmo quando você precisa de colunas calculadas, isso também pode ser definido no Power BI Desktop. Faça isso criando colunas ou medidas calculadas depois de importar os dados. Será recomendável usar somente objetos de página como conjuntos de dados para o Power BI se você precisar de determinado cálculo ou execução da lógica comercial usando o código AL, que não pode ser executado no Power BI Desktop após a importação dos dados.
Extrações eficientes para data lakes ou data warehouses
Ao estabelecer um data lake ou um data warehouse, normalmente é necessário fazer dois tipos de extração de dados:
Uma carga histórica (todos os dados de certo ponto no tempo)
Cargas Delta (o que foi alterado desde a carga histórica)
A forma mais rápida (e menos prejudicial) de obter uma carga histórica do Business Central online é obter uma exportação de banco de dados como um arquivo BACPAC (usando o centro de administração do Business Central) e restaurá-la em um Banco de dados SQL do Azure ou em um SQL Server. Para instalações locais, você pode fazer um backup do banco de dados de locatários.
A forma mais rápida (e menos perturbador) de obter cargas Delta no Business Central online é definir consultas de API configuradas com a escala de leitura e usar o campo de auditoria de dados LastModifiedOn (apresentada na versão 17.0) em filtros.
Gravar serviços Web eficientes
O Business Central oferece suporte a serviços Web para facilitar a integração com sistemas externos. Como desenvolvedor, você precisa pensar no desempenho de serviços Web para o Business Central Server (o ponto de extremidade) e o consumidor (o cliente).
Evite o uso de páginas de interface de usuário padrão para expor como pontos de extremidade de serviço Web. Muitos itens, como Caixas de Dados, não são expostos no OData, mas usam os recursos para calcular.
As coisas que historicamente causaram o desempenho nas páginas que são expostas como pontos de extremidade são:
Lógica pesada no OnAfterGetCurrRecord
Muitos campos de SIFT
Caixas de Dados
Usar a Expansão de leitura
O Business Central oferece suporte ao recurso de scale-out de leitura no Banco de Dados SQL do Azure e no SQL Server. A escalabilidade de leitura é usada para equilibrar a carga de cargas de trabalho analíticas no banco de dados que somente leem. A escala de leitura é interna como parte do Business Central Online, mas também pode ser habilitada para versões locais.
A escala de leitura se aplica a consultas, relatórios ou páginas de API. Com esses objetos, em vez de compartilhar o principal, eles podem ser configurados para serem executados em uma réplica somente leitura. Essa configuração o isola essencialmente da carga de trabalho de leitura-gravação principal para que elas não afetem o desempenho de processos comerciais.
Como desenvolvedor, controle a Escala de Leitura em relatórios, as páginas API e os objetos de consulta usando a propriedade DataAccessControl.
A propriedade DataAccessIntent define se é necessário obter dados para o objeto a partir de uma réplica somente leitura do banco de dados ou do banco de dados primário.
A propriedade tem os seguintes valores:
ReadOnly: especifica para obter os dados de uma réplica somente leitura.
ReadWrite: especifica para obter os dados do banco principal. ReadWrite é o valor padrão.
Para relatórios, páginas de API e consultas, o Business Central Server pode usar réplicas de banco de dados somente leitura no Banco de Dados SQL do Azure. Se as réplicas estiverem habilitadas, use esta propriedade para reduzir a carga no banco de dados principal.
O uso de ReadOnly também pode melhorar o desempenho ao exibir objetos. ReadOnly funciona como uma dica para o servidor rotear a conexão para uma réplica secundária (somente leitura), se houver uma disponível. Quando uma carga de trabalho é executada em relação à réplica, as operações de inserção/exclusão/modificação não são possíveis. Se qualquer uma dessas operações for executada na réplica, uma exceção será lançada no tempo de execução.
A partir do cliente, o valor da propriedade pode ser substituído usando a página de lista de tentativas de acesso a banco de dados 9880.
Dicas de desempenho para trabalhar com o Power BI e o Business Central
Tendo em mente as informações anteriores, você provavelmente entendeu que é importante manter um olho no desempenho, especialmente ao criar relatórios do Power BI no Business Central. Veja a seguir algumas questões a serem consideradas.
É melhor criar uma nova consulta ou uma nova página e usá-la como uma fonte de dados dedicada para o Power BI, em vez de usar páginas ou consultas existentes que também servem a outras finalidades. Personalizando o conjunto de dados (página/consulta) para seu relatório específico do Power BI, você só precisará incluir os campos necessários, nada mais.
Em uma situação, quando você pode escolher, deve escolher consultas sobre páginas como fontes de dados para o Power BI. Os objetos de consulta geram uma declaração de seleção melhor e mais rápida no banco de dados SQL e os objetos de consulta também podem agregar. Você deve criar as consultas de forma que elas só retornam os dados necessários para o relatório do Power BI, nada mais. Por exemplo, se o relatório exigir dados de vendas por dia, crie um objeto de consulta em que você pesquisa os dados de vendas e os agrega por dia. Em vez de buscar vários registros para determinado dia e permitir que o Power BI agregue os registros após a importação.
Implemente filtros em consultas e páginas. Se houver registros nas tabelas de origem subjacentes que não são necessários no relatório, você deverá filtrá-los assim que possível.
Não inclua campos ou colunas que não são necessários no seu conjunto de dados. Você sempre pode adicioná-los mais tarde, quando necessário e o serviço Web é atualizado automaticamente.
Se você precisar de informações das tabelas de entrada do razão, certifique-se de que os registros foram agregados. As tabelas de entrada do razão contêm vários registros e geralmente continuam crescendo. É muito improvável que você precise importar e visualizar cada entrada do razão individual em um relatório do Power BI. Portanto, crie a consulta com o nível de agregação que corresponde aos requisitos do relatório.
Como recomendação, sugiro o uso de objetos de consulta em vez de objetos de página. Isso ocorre porque os objetos de consulta geralmente geram instruções SQL mais rápidas, eles podem associar várias tabelas e dados agregados.
Os objetos de página permitem calcular os campos usando a linguagem de programação AL, enquanto os objetos de consulta não podem fazer isso. No entanto, você deve saber que o Power BI também é capaz de criar colunas e medidas calculadas usando o idioma Dax. Então, em vez de criar um objeto de página com cálculos complexos em AL-Code, é provável que seja melhor criar um objeto de consulta e permitir que o Power BI realize cálculos complexos, depois que os dados são importados.