Valutazione dell'impatto sulle prestazioni
Power BI può connettersi ai servizi Web pubblicati da Business Central e basati su oggetti di tipo query o pagina. Le differenza principale tra un servizio Web di tipo pagina e uno di tipo query è:
Pagina
Può usare una tabella di origine
Può contenere logica AL e colonne calcolate
Può contenere campi di flusso
Viene memorizzata nella cache a livello di servizio
Esegue sempre un'istruzione SELECT * nella tabella di origine sottostante, indipendentemente dalle colonne definite nell'oggetto pagina
Query
Può unire più tabelle di origine
Può calcolare aggregazioni
Non può contenere logica AL né colonne calcolate
Può contenere campi di flusso
Non viene memorizzata nella cache a livello di servizio
Esegue le istruzioni SELECT solo per le colonne definite come colonne nell'oggetto query
Query API
Può unire più tabelle di origine (più veloce di Pagina API)
Può calcolare aggregazioni
Non può contenere logica AL né colonne calcolate
Può contenere campi di flusso
Non viene memorizzata nella cache a livello di servizio
Esegue le istruzioni SELECT solo per le colonne definite come colonne nell'oggetto query
Non è necessario pubblicare nella tabella Servizi Web
Come si potrebbe aver riscontrato, le prestazioni degli oggetti query sono in genere migliori di quelle degli oggetti pagina. Per questo motivo, come origini dati per Power BI si consiglia di creare o usare oggetti query. Anche quando sono necessarie colonne calcolate, è possibile definirle in Power BI Desktop. A tale fine, creare colonne calcolate o misure dopo aver importato i dati. Si consiglia di usare gli oggetti pagina come set di dati per Power BI solo nei casi in cui siano necessari determinati calcoli o esecuzioni di logica di business tramite codice AL, che non è possibile eseguire in Power BI Desktop dopo l'importazione dei dati.
Estrazioni efficienti in data lake o data warehouse
Quando si stabilisce un data lake o un data warehouse, in genere è necessario eseguire due tipi di estrazione dei dati:
Un carico storico (tutti i dati da un determinato momento)
Carichi delta (cosa è cambiato dal carico storico)
Il modo più rapido (e meno invasivo) per ottenere un carico cronologico da Business Central Online consiste nell'ottenere un'esportazione del database come file BACPAC (usando l'interfaccia di amministrazione di Business Central) e ripristinarlo in un database SQL di Azure o in SQL Server. Per le installazioni locali, è possibile semplicemente eseguire un backup del database tenant.
Il modo più rapido (e meno invasivo) per ottenere carichi delta da Business Central Online consiste nell'impostare query API configurate con scalabilità orizzontale in lettura e utilizzare il campo di controllo dei dati LastModifiedOn (introdotto nella versione 17.0) sui filtri.
Scrittura di servizi Web efficienti
Per semplificare l'integrazione con i sistemi esterni, Business Central supporta i servizi Web. Gli sviluppatori devono tenere in considerazione le prestazioni dei servizi Web sia per quanto riguarda il server Business Central (endpoint) che per il consumatore (client).
Si consiglia di evitare di usare pagine di interfaccia utente standard da esporre come endpoint di servizio Web. Molti elementi, come i riquadri Dettaglio informazioni, non sono esposti in OData ma usano risorse per il calcolo.
In genere, gli elementi esposti come endpoint che storicamente hanno causato problemi di prestazioni sono i seguenti:
Logica pesante in OnAfterGetCurrRecord
Molti campi SIFT
Riquadri Dettaglio informazioni
Uso della funzionalità Scalabilità in lettura
Business Central supporta la funzionalità Scalabilità in lettura nel database SQL di Azure e in SQL Server. Questa funzionalità consente di bilanciare i carichi di lavoro analitici nel database di sola lettura dei dati, è integrata in Business Central Online, ma può essere abilitata anche per le versioni locali.
La funzionalità Scalabilità in lettura si applica a pagine API, report o query. Quando si usano questi oggetti, è possibile impostare l'esecuzione in una replica di database di sola lettura, anziché condividere il database primario. Questa configurazione consente essenzialmente di isolare gli oggetti dal carico di lavoro di lettura-scrittura principale in modo che non influiscano sulle prestazioni dei processi aziendali.
Gli sviluppatori possono controllare la Scalabilità in lettura in oggetti query, pagine API e report tramite la proprietà DataAccessControl.
La proprietà DataAccessIntent specifica se recuperare i dati per l'oggetto da una replica di sola lettura del database o dal database primario.
La proprietà può avere i valori seguenti:
ReadOnly: specifica che i dati devono essere recuperati da una replica di database di sola lettura.
ReadWrite: specifica che i dati devono essere recuperati dal database primario. Il valore predefinito è ReadWrite.
Per report, pagine API e query, il server Business Central può usare repliche di database di sola lettura nel database SQL di Azure e in SQL Server. Se sono abilitate le repliche, è possibile usare questa proprietà per ridurre il carico nel database primario.
L'uso della proprietà ReadOnly potrebbe migliorare le prestazioni anche durante la visualizzazione degli oggetti. La proprietà ReadOnly si usa come hint per fare in modo che il server indirizzi la connessione verso una replica di database secondaria (di sola lettura), se disponibile. Se un carico di lavoro viene eseguito nella replica di database, non è possibile effettuare operazioni di inserimento, eliminazione o modifica. Se si esegue una di queste operazioni nella replica, in fase di runtime viene generata un'eccezione.
È possibile sovrascrivere il valore della proprietà dal client usando la pagina 9880: Lista intenti di accesso al database.
Suggerimenti per migliorare le prestazioni di Power BI e Business Central
In base alle informazioni precedenti, è chiaro come sia importante tenere sotto controllo le prestazioni, soprattutto durante la creazione di report di Power BI in Business Central. Di seguito sono indicati alcuni aspetti da considerare.
Come origine dati dedicata per Power BI, è meglio creare una nuova query o una nuova pagina anziché usare pagine o query esistenti usate anche per altri scopi. Se si personalizza il set di dati (pagina/query) per il report Power BI specifico, è opportuno includere solo i campi indispensabili, niente di più.
In situazioni in cui è possibile scegliere l'origine dati per Power BI, si consigliano gli oggetti query, anziché gli oggetti pagina. Le query consentono di generare istruzioni SELECT con prestazioni più efficaci e veloci nel database SQL, offrono inoltre la possibilità di aggregare i dati. È opportuno creare le query in modo che restituiscano solo i dati necessari per il report di Power BI, niente di più. Ad esempio, se il report richiede dati sulle vendite giornalieri, creare un oggetto query che recuperi i dati sulle vendite e li aggreghi per giorno, anziché recuperare più record per un determinato giorno e quindi usare Power BI per aggregarli dopo l'importazione.
Implementare i filtri nelle query e nelle pagine. Se nelle tabelle di origine sottostanti sono presenti record non indispensabili ai fini del report, è opportuno filtrarli il prima possibile.
Non includere campi o colonne non necessari nel set di dati. È sempre possibile aggiungerli successivamente in base alle esigenze, il servizio Web si aggiornerà automaticamente.
Se si devono includere dati di tabelle Movimenti contabili, assicurarsi di prevedere l'aggregazione dei record. Le tabelle Movimenti contabili contengono molti record che, in genere, sono in continuo aumento. In un report Power BI l'esigenza di importare e visualizzare ogni singolo movimento contabile è estremamente improbabile. Pertanto, è opportuno creare una query che preveda un livello di aggregazione corrispondente agli effettivi requisiti del report.
Come raccomandazione, si consiglia di usare oggetti query anziché oggetti pagina. Gli oggetti query consentono infatti di generare istruzioni SQL più veloci, possono creare join tra più tabelle e aggregare i dati.
Gli oggetti pagina consentono di calcolare i campi usando il linguaggio di programmazione AL, operazione che non è possibile eseguire con gli oggetti query. È utile sapere che Power BI consente di creare misure e colonne calcolate anche con il linguaggio DAX. Di conseguenza, anziché creare un oggetto pagina con calcoli complessi in codice AL, probabilmente è meglio creare un oggetto query e affidare l'esecuzione dei calcoli complessi, a Power BI, dopo l'importazione dei dati.