Bijvoorbeeld request 80000bda-0006-a200-b63f-84710c7967bb
Vanuit Exact Online wordt de tabel ExactOnlineREST.Financial.ReportingBalance@eol opgehaald via OData4. Het betreft hier 8.000 rijen waarbij alleen de jaren 2022 en recenter worden opgehaald en betreft 1 divisie code (de basistabel zonder filter op jaar bestaat uit 14.000 rijen en gaat terug tot 2017).
SQL-instructie
select t.[Amount], t.[BalanceType], t.[Count], t.[GLAccountCode], t.[GLAccountDescription], t.[ID], t.[ReportingPeriod], t.[ReportingYear], t.[Type] from ExactOnlineREST.Financial.ReportingBalance@eol t where ((((((((((([Division] = :w1) or ([Division] is null )) or ([Division] is null )) or ([Division] is null )) or ([Division] is null )) or ([Division] is null )) or ([Division] is null )) or ([Division] is null )) or ([Division] is null )) or ([Division] is null )) and ([ReportingYear] >= :w2))
De totale duur om de 8.000 rijen op te halen is 492.871 ms; wat neerkomt om ongeveer 10 minuten. Bij 10 minuten is er de standaard time-out; wat ook voor kan komen.
Gezien de hoeveelheid rijen, is de tijd die nodig is fors lang.
Waarom heeft Power Query / Bridge Online zoveel tijd nodig en hoe kan dit aanzienlijk verkort worden?
Ter vergelijk (request 80000b22-0004-ae00-b63f-84710c7967bb) haalt in 23.008 ms 50.953 rijen op; voor dezelfde divisie uit Exact Online tabel ExactOnlineREST.Incremental.TransactionLinesIncremental met dezelfde OData4 koppeling.
Het gebruik van ReportingBalance wordt afgeraden voor alleen saldi en in bijzonder bij toepassingen waarbij er veel kostenplaats/kostendragercombinaties zijn. Het door Exact gekozen ontwerp van ReportingBalance zorgt voor een relatief groot gebruik van Exact Online API-calls en lange doorlooptijden.
Het aanbevolen alternatief is BalanceLinesPerPeriod. Voor gebruik met kostenplaats/kostendragercombinatie is het aanbevolen alternatief `BalanceLinesPerPeriodCostAnalysis’.
Zie voor meer informatie onder “Exact Online XML API and Popular Tables” op:
Een Power BI time-out kan voorkomen worden door de time-out hoger in te stellen zoals beschreven in:
Merk op dat Invantive Cloud standaard real-time werkt; data wordt pas verzameld op het moment dat een query ontvangen wordt. Zie ook:
Het cachegedrag kan geconfigureerd worden zoals beschreven in:
Meer tips om de meest voorkomende hindernissen op te lossen staan beschreven in:
Zowel ExactOnlineREST.Balances.BalanceLinesPerPeriodAll@eol als ExactOnlineREST.Balances.BalanceLinesPerPeriodCostAnalysisAll@eol zijn niet inlaadbaar in het Invantive Rapid sjabloon 23-3-2023. Namelijk beide geven als foutmelding dat het veld Division niet gevonden kan worden. Deze wordt via #“eol-division-code-1” op de division code (administratie) in Exact Online gefilterd om alleen die ene administratie op te halen.
Is het sjabloon niet up-to-date of gaat er iets anders niet naar behoren?
Ik wil in Power Query eenzelfde resultaat als ik uit tabel ExactOnlineREST.Financial.ReportingBalance@eol krijg om tabel tabel ExactOnlineREST.Financial.ReportingBalance@eol te vervangen door één van de twee alternatieven.
De tabel BalanceLinesPerPeriod: Exact Online Balansregels per Periode lijkt op basis van documentatie BalanceLinesPerPeriod: Exact Online Balansregels per Periode (invantive.com) te voldoen. De tabel BalanceLinesPerPeriodCostAnalysis is (vooralsnog) te gedetailleerd vanwege de uitsplitsing naar CostCenters.
Het sjabloon zocht het veld code, terwijl in de tabel Division_code de filter is om de administratie te selecteren. De tabel BalanceLinesPerPeriod kolom Division_code wordt ingeladen als tekst waarde, terwijl het filter op administratie een datatype Getal verwacht.
Inmiddels de tabel aan het inladen. Het lijkt er op dat er (nog) meer dat wordt ingeladen dan bij de ReportingBalance. Ik ben in Power Query een en ander aan het filteren, zodat slecht hetgeen ik nodig heb aan data wordt ingeladen. Vreemd is dat Bridge Online vooralsnog geen filters lijkt mee te nemen in request 80000d21-0005-f600-b63f-84710c7967bb:
SQL-instructie
select t.*
from ExactOnlineREST.Balances.BalanceLinesPerPeriodCostAnalysisAll@eol t
Deze vraag is automatisch gesloten na 2 weken inactiviteit. Het laatste gegeven antwoord is gemarkeerd als oplossing.
Gelieve een nieuwe vraag te stellen via een apart topic als het probleem opnieuw optreedt. Gelieve in de nieuwe vraag een link naar dit topic op te nemen door de URL er van in de tekst te plakken.