Die Auswirkungen auf die Leistung abwägen
Power BI kann eine Verbindung zu den von Business Central veröffentlichten Webdiensten herstellen. Diese Webdienste basieren auf Seiten‑ oder Abfrageobjekten. Der Hauptunterschied zwischen einem Seitenwebdienst und einem Abfragewebservice ist der folgende:
Seite
Kann eine Quelltabelle verwenden
Kann AL-Logik und berechnete Spalten enthalten
Kann Flow-Felder enthalten
Ist auf der Dienstschicht zwischengespeichert
Führt immer SELECT * in der zugrunde liegenden Quelltabelle aus, unabhängig von den definierten Spalten im Seitenobjekt
Abfrage
Kann mehrere Quelltabellen verbinden
Kann Aggregationen berechnen
Kann keine AL-Logik oder berechnete Spalten enthalten
Kann Flow-Felder enthalten
Ist nicht auf der Dienstschicht zwischengespeichert
Führt SELECT nur für die Spalten aus, die als Spalten im Abfrageobjekt definiert sind
API-Abfrage
Kann mehreren Quelltabellen beitreten (schneller als API-Seite)
Kann Aggregationen berechnen
Kann keine AL-Logik oder berechnete Spalten enthalten
Kann Flow-Felder enthalten
Ist nicht auf der Dienstschicht zwischengespeichert
Führt SELECT nur für die Spalten aus, die als Spalten im Abfrageobjekt definiert sind
Muss nicht in der Tabelle „Webdienste“ veröffentlicht werden
Wie Sie vielleicht erfahren haben, ist die Leistung von Abfrageobjekten normalerweise besser als die Leistung von Seitenobjekten. Aus diesem Grund wird empfohlen, Abfrageobjekte als Datenquellen für Power BI zu erstellen oder zu verwenden. Sie können dies auch in Power BI Desktop, wenn Sie berechnete Spalten benötigen. Nachdem Sie die Daten importiert haben, erstellen Sie berechnete Spalten oder Kennzahlen, um dies zu tun. Es wird empfohlen, nur Seitenobjekte als Datensätze für Power BI zu verwenden, wenn Sie eine bestimmte Berechnung oder Ausführung der Geschäftslogik mit AL-Code benötigen, kann dies nicht in Power BI Desktop ausgeführt werden, nachdem Daten importiert wurden.
Effiziente extrahierte Daten in Data Lakes oder Data Warehouses
Bei der Einrichtung von einem Data Lake oder einem Data Warehouse müssen Sie in der Regel zwei Arten der Datenextraktion durchführen:
Eine historische Last (alle Daten ab einem bestimmten Zeitpunkt)
Delta-Ladungen (Veränderungen seit dem historischen Ladevorgang)
Der schnellste (und am wenigsten störende) Weg, um eine historische Ladung von Business Central Online zu erhalten, besteht darin, einen Datenbankexport als BACPAC-Datei (unter Verwendung des Business Central Admin Center) zu erhalten und ihn in einer Azure SQL-Datenbank oder auf einem SQL Server wiederherzustellen. Sie können bei lokalen Installationen einfach eine Sicherung der Mandantendatenbank erstellen.
Der schnellste (und am wenigsten störende) Weg, Deltalasten von Business Central Online zu erhalten, ist das Einrichten von API-Abfragen, die mit Leseskalierung konfiguriert sind, und die Verwendung des Datenüberwachungsfelds LastModifiedOn (eingeführt in Version 17.0) für Filter.
Effiziente Webdienste schreiben
Business Central unterstützt Webdienste, um die Integration in externe Systeme zu vereinfachen. Als Entwickler müssen Sie über die Leistung von Webdiensten sowohl für den Business Central Server (Endpunkt) als auch für den Verbraucher (Client) nachdenken.
Vermeiden Sie die Verwendung von Standard-UI-Seiten als Webdienst-Endpunkte. Viele Dinge, wie Infoboxen, werden in OData nicht angezeigt, verwenden jedoch Ressourcen zum Berechnen.
Dinge, die in der Vergangenheit zu Leistung auf Seiten geführt haben, die als Endpunkte verfügbar gemacht werden, sind:
Schwere Logik in OnAfterGetCurrRecord
Viele SIFT-Felder
Infoboxen
Verwenden der horizontalen Leseskalierung
Business Central unterstützt die Funktion Horizontale Leseskalierung in Azure SQL-Datenbank und SQL Server. Die horizontale Leseskalierung wird verwendet, um analytische Workloads in der Datenbank auszugleichen, die nur Daten lesen. Die horizontale Leseskalierung ist als Teil von Business Central Online integriert, kann jedoch auch für lokale Versionen aktiviert werden.
Die horizontale Leseskalierung gilt für Abfragen, Berichte oder API-Seiten. Mit diesen Objekten können sie anstelle der Freigabe der primären Objekte so eingerichtet werden, dass sie für ein schreibgeschütztes Replikat ausgeführt werden. Dieses Setup isoliert sie im Wesentlichen von der Hauptarbeitslast beim Lesen und Schreiben, sodass sie die Leistung von Geschäftsprozessen nicht beeinträchtigen.
Als Entwickler steuern Sie Horizontale Leseskalierung für Berichte, API-Seiten und Abfrageobjekte mithilfe der Eigenschaft DataAccessControl.
Die Eigenschaft DataAccessIntent legt fest, ob Daten für das Objekt von einem schreibgeschützten Replikat der Datenbank oder der primären Datenbank abgerufen werden sollen.
Die Eigenschaft verfügt über die folgenden Werte:
ReadOnly – Gibt an, dass die Daten von einem schreibgeschützten Replikat abgerufen werden sollen.
ReadWrite – Gibt an, dass die Daten aus der Primärdatenbank abgerufen werden sollen. ReadWrite ist der Standardwert.
Für Berichte, API-Seiten und Abfragen kann der Business Central Server schreibgeschützte Datenbankreplikate in Azure SQL-Datenbank und SQL Server verwenden. Wenn Replikate aktiviert sind, verwenden Sie diese Eigenschaft, um die Belastung der Primärdatenbank zu verringern.
Das Verwenden von ReadOnly kann auch die Leistung beim Anzeigen von Objekten verbessern. ReadOnly dient als Hinweis für den Server, um die Verbindung zu einem sekundären (schreibgeschützten) Replikat weiterzuleiten, sofern eines verfügbar ist. Wenn eine Arbeitslast für das Replikat ausgeführt wird, sind Einfüge-/Lösch‑/Änderungsvorgänge nicht möglich. Zur Laufzeit wird eine Ausnahme ausgelöst, wenn eine dieser Operationen für das Replikat ausgeführt wird.
ClientVom Client aus kann der Eigenschaftswert mithilfe von Seite 9880 Liste der Datenbankzugriffsabsichten überschrieben werden.
Leistungstipps für die Arbeit mit Power BI und Business Central
Wenn Sie die vorherigen Informationen berücksichtigen, verstehen Sie wahrscheinlich, dass es wichtig ist, die Leistung im Auge zu behalten, insbesondere beim Erstellen von Power BI-Berichten in Business Central. Sie sollten dabei die folgenden Aspekte berücksichtigen.
Es ist besser, eine neue Abfrage oder eine neue Seite zu erstellen und diese als dedizierte Datenquelle für Power BI zu verwenden, anstatt vorhandene Seiten oder Abfragen zu verwenden, die auch anderen Zwecken dienen. Indem Sie Ihren Datensatz (Seite/Abfrage) an Ihren spezifischen Power BI-Bericht anpassen, müssen Sie nur die Felder einschließen, die Sie benötigen, nichts weiter.
In einer Situation, in der Sie auswählen können, sollten Sie Abfragen über Seiten als Datenquellen für Power BI auswählen. Abfrageobjekte generieren eine bessere, schnellere select-Anweisung in der SQL-Datenbank, und Abfrageobjekte können auch Daten aggregieren. Sie sollten die Abfragen so erstellen, dass sie nur die Daten zurückgeben, die für den Power BI-Bericht erforderlich sind, nichts weiter. Erstellen Sie ein Abfrageobjekt, in dem Sie die Verkaufsdaten abrufen und nach Tag aggregieren, wenn Ihr Bericht zum Beispiel Verkaufsdaten pro Tag erfordert. Anstatt mehrere Datensätze für einen bestimmten Tag abzurufen und dann Power BI die Datensätze nach dem Import zusammenfassen zu lassen.
Implementieren Sie Filter in Abfragen und Seiten. Wenn die zugrunde liegenden Quelltabellen Datensätze enthalten, die in Ihrem Bericht nicht erforderlich sind, sollten Sie sie so schnell wie möglich herausfiltern.
Fügen Sie keine Felder oder Spalten hinzu, die nicht in Ihrem Dataset erforderlich sind. Sie können sie bei Bedarf jederzeit später hinzufügen, und der Webdienst wird automatisch aktualisiert.
Wenn Sie Informationen aus Artikelpostentabellen benötigen, stellen Sie sicher, dass Sie die Datensätze aggregieren. Artikelpostentabellen enthalten viele Datensätze und wachsen normalerweise weiter. Es ist sehr unwahrscheinlich, dass Sie jeden einzelnen Artikelposten in einen Power BI-Bericht importieren und visualisieren müssen. Erstellen Sie daher die Abfrage mit der Aggregationsebene, die den Anforderungen für den Bericht entspricht.
Als Empfehlung würde ich vorschlagen, Abfrageobjekte anstelle von Seitenobjekten zu verwenden. Dies liegt daran, dass Abfrageobjekte im Allgemeinen schnellere SQL-Anweisungen generieren. Sie können mehrere Tabellen verknüpfen und Daten aggregieren.
Mit Seitenobjekten können Sie Felder mit der Programmiersprache AL berechnen, während Abfrageobjekte dies nicht können. Sie sollten jedoch wissen, dass Power BI auch in der Lage ist, berechnete Spalten und Kennzahlen in der DAX-Sprache zu erstellen. Anstatt ein Seitenobjekt mit komplexen Berechnungen in AL-Code zu erstellen, ist es wahrscheinlich besser, ein Abfrageobjekt zu erstellen und zuzulassen, dass Power BI die komplexen Berechnungen durchführt, nachdem die Daten importiert wurden.