De performance van deze views zijn zeer traag binnen onze omgeving en dat komt waarschijnlijk doordat de view alle informatie ophaald ongeacht de rechten van gebruiker. Bij een andere klant is dat geen issue, omdat de administratie daar zeer beperkt is.
Het kan inderdaad zijn dat op grote omgevingen er veel data opgehaald wordt. Voor de snelheid zijn we afhankelijk van de achterliggende API.
Advies is daarom in Power BI te filteren op de relevante data. Bij het ophalen zal dan als het goed is slechts een gedeelte van de data opgehaald worden. Is dat mogelijk?
Er wordt inderdaad gebruik gemaakt van filters, maar de view bevat informatie van alle administraties ongeacht of de gebruiker toegang heeft tot deze administratie. In ons geval worden daardoor honderdduizenden rijen geladen terwijl het slechts enkele duizenden moeten zijn.
Dat klopt helemaal, alhoewel op basis van de gebruiker zou toch niet alle informatie getoond moeten worden. Het account dat gebruikt is heeft slechts toegang tot 1 administratie, maar krijgt alles te zien.
Views kunnen ook gefilterd worden door Invantive Universal SQL. Daarvoor zijn dan wel filters nodig die doorgegeven worden. Ik kan zo niet vaststellen waarom de filters niet doorkomen vanuit Power BI.
Het is ook altijd mogelijk zelf aan de hand van SQL een view te maken bij het opstarten van de database waarbij al ‘voorgekookt’ de data beschikbaar wordt gemaakt.
Dit is vergelijkbaar met algemene tabellen zoals “landen” en “munteenheden”, waar iedere gebruiker dezelfde lijst van landen of munteenheden ziet en gebruikt.
De tabeleigenschappen zijn aangepast. De prestaties zullen hierdoor in omgevingen met bijvoorbeeld 10 hierarchien en 1000 bedrijven stijgen met een factor maximaal 1 miljoen.
Dit is een “breaking change” omdat de kolommen company_code en company_name verdwijnen uit de kolommenlijst. Daarom is ook meteen een typo gecorrigeerd, namelijk de prefix hierachy is gecorrigeerd naar hierarchy in de twee bovengenoemde views.
De wijzigingen zullen effectief worden in release 24.0.98 en worden naar verwachting voor 25 maart 2024 in productie genomen op Invantive Cloud.
De responsetijden zijn sterk verbeterd, in een testopstelling bijvoorbeeld:
Hierarchies: 569 ms,
GeneralLedgerAccountMappings met filter op hierarchy_CODE: 293 ms,
GeneralLedgerAccountMappingAccounts met filter op hierarchy_CODE: 332 ms.
Een nieuwe release 24.0.101 is in productie genomen op Invantive Cloud die de snelheid significant zou moeten verhogen.
Merk op dat een aantal velden vervallen zijn, zoals velden die beginnen met company_ omdat de gegevens abonnementsbreed zijn en niet administratief-specifiek.
Ik krijg nu onderstaande foutmelding als ik de view opvraag. In de lijst met tabellen en views kom ik geen alternatieven tegen. Is de nieuwe view nog niet beschikbaar?
DataSource.Error:
OData:
Aanvraag mislukt:
The remote server returned an error: (500) Internal Server Error.
(Onbekende tabel ‘GENERALLEDGERACCOUNTMAPPINGACCOUNTSBYHIERARCHYCODETEST1’.
Mogelijke geldige alternatieven:
GeneralLedgerAccountMappingAccountsByHierarchyCode, GeneralLedgerAccountMappingAccounts
(itgengpr015, 27db3e9d-7d1d-4598-af9b-ca34ae790976))
