Error itgenboe147 ook na optimaliseren queries voor Exact Online PurchaseOrderLines

Wij blijven iedere week foutmeldingen krijgen van jullie. Ik heb reeds de queries aangepast naar:

Source = OData.Feed(#“bridge-url”, null, [Implementation=“2.0”, ODataVersion=4, OmitValues=ODataOmitValues.Nulls, Headers=[Referer = “enter-your-chosen-id-for-the-source” ], Timeout=#duration(0,4,0,0)]).

Hoe lossen we dit op?

Er is een fout opgetreden met code ‘itgenboe147’ toen Invantive Cloud een proces voor u uitvoerde.
Het downloaden van gegevens werd geannuleerd na 5 minuten, 17 seconden, waarschijnlijk vanwege een ontbrekende of onjuist geconfigureerde time-out in de Power BI- of Power Query-query. Optimaliseer uw query zoals beschreven op Overview of Power BI Performance and Download Size Improvement Techniques - invantive. Zorg ervoor dat u handmatig een voldoende hoge time-out configureert op de OData-feed zoals beschreven op Avoid timeout error on Power BI OData download - invantive. Voer vervolgens de query opnieuw uit.
Tabelnaam: ExactOnlineREST.PurchaseOrder.PurchaseOrderLines
SQL Select-statement:
select t.[AmountDC], t.[AmountFC], t.[CostCenter], t.[CostCenterDescription], t.[CostUnit], t.[CostUnitDescription], t.[Description], t.[Division], t.[ID], t.[InStock], t.[InvoicedQuantity], t.[Item], t.[ItemCode], t.[ItemDescription], t.[NetPrice], t.[Notes], t.[PurchaseOrderID], t.[Quantity], t.[SupplierItemCode], t.[Unit], t.[UnitDescription], t.[UnitPrice]
from [ExactOnlineREST.PurchaseOrder.PurchaseOrderLines@eol] t
where ([Division] = :w1)

In de Invantive Bridge Online Monitoring is terug te vinden dat het ophalen van PurchaseOrderLines voor dit account sterk varieert. Het gaat om minder dan 6.000 regels.

De ene keer om 05:10 UTC duurt het 5 minuten of langer en wordt het afgebroken. De andere keer om 05:35 UTC duurt het 19 seconden.

Het afbreken bij een OData download na circa 5 minuten ondanks significant hogere timeout-waardes treedt de afgelopen tijd regelmatig op bij gebruik van PowerBI.com. Dit probleem treedt voor zover bekend niet op bij het gebruik van Azure Data Factory, Power BI Desktop en Power Query. De oorzaak is nog onbekend, het lijkt een PowerBI.com probleem; we onderzoeken dit nog in de hoop het reproduceerbaar te krijgen en te kunnen melden bij Microsoft of een workaround te bieden.

De tabel PurchaseOrderLines benodigt circa 100 API calls op Exact Online, wat sinds de wijzigingen van vorig jaar tenminste 100 seconden duurt. Het feit dat het om 05:35 UTC maar 19 seconden duurt, geeft aan dat een deel van de HTTP-cache gebruikt wordt die gevuld is door het voorgaande verzoek van 05:10 UTC.

Vreemd genoeg probeert PowerBI.com dus ook niet herhaaldelijk de gegevens op te halen zoals eerder.

Naast dat we zoeken naar de oorzaak van dit incidenteel optredende probleem zijn er de volgende opties:

  • Nu: beperk het aantal parallelle downloads tot 1 in PowerBI.com. Bij het gebruik van parallel real-time downloads wordt de limiet van 1 API-call per seconde naar Exact Online door alle parallelle downloads gedeeld. De download van PurchaseOrderLines zal dan na circa 100 seconden klaar zijn.
  • Iets langere termijn: overstappen op PurchaseOrderLinesIncremental; deze tabel komt binnen 7 dagen beschikbaar en is vele malen sneller.

De tabel PurchaseOrderLinesIncremental zal - bij succesvol afronden tests - samen met ProjectPlanningsIncremental 28 april 2022 in productie beschikbaar zijn. Hou hierbij rekening met bedrijfssluiting i.v.m. nationale feestdag op 27 april 2022.

Daarnaast zullen een aantal views toegevoegd binnen het DataDictionary zodat het eenvoudiger wordt om geautomatiseerd dergelijke storingen in PowerBI.com te analyseren en reproduceerbaar te maken, los van de daadwerkelijke databron:

Naam #Rijen Volume (MB) Duur (sec)
Test100Rows1Mb100Sec 100 1 100
Test10000Rows100Mb100Sec 10.000 100 100
Test10Rows1000Mb1Sec 10 1.000 1
Test1000000Rows1000Mb1Sec 1.000.000 1.000 1*
Test1000000Rows1000Mb1000Sec 1.000.000 1.000 1.000
Test1000000Rows1000Mb10000Sec 1.000.000 1.000 10.000
  • De daadwerkelijke duur zal langer dan 1 seconde zijn; de 1 seconde moet gelezen worden als: zonder toegevoegde vertraging en beperkt door snelheid omgeving. Dit geldt in minder mate ook voor de andere nieuwe views.

Niet enkel krijgen wij foutmeldingen van Purchasorderlines, ook kregen we vandaag opnieuw een foutmelding, deze keer over de tabel ExactOnlineREST.Financial.ReportingBalance? Hoe lossen we dit op?


Hoe kan ik mijn query in dataflow nog verder optimaliseren zodat er geen problemen meer zijn?

Dank voor delen query. Het advies valt uiteen in drie delen.

Advies 1: BalanceLinesPerPeriodCostAnalysis in plaats van ReportingBalance

De getoonde query is op ReportingBalance. Dit is niet de meest efficiënte Exact Online API om per kostenplaats/kostendrager de saldi op te halen. Het is goed om bij financiele rapportages altijd als ezelbruggetjes in het hoofd te houden dat de wijze waarin de XML API’s van Exact Online gemaakt zijn blijkbaar het accountingproces beter begrepen werd dan in de REST API’s, ook al zal die laatste veel recenter gebouwd met behulp van meer resources. Kom je er niet uit met een REST API, kijk dan altijd bij de XML API’s.

Het eerste advies is om daarom te wisselen naar BalanceLinesPerPeriodCostAnalysis. Die is meestal significant sneller, maar niet meer dan 10x sneller.

De wijze waarop ReportingBalance wordt uitgelezen is goed. De filterstap zit netjes heel dicht tegen het ophalen aan, waardoor het administratienummer (divisiecode) doorgegeven wordt aan Invantive Cloud en die er ook op kan filteren. Verder zijn er geen filterstappen zichtbaar.

Advies 2: minder auto’s op de weg

Verder blijkt uit een analyse van de downloads dat de downloads van ReportingBalance regelmatig circa 1-2 minuten staan te wachten tot ze mogen beginnen. Dit is meestal een teken dat er teveel en te grote downloads tegelijk gestart worden. Bijvoorbeeld als er 8 downloads tegelijk vanuit Power BI gestart worden, dan mogen er met een standaard Invantive-abonnement maar 4 tegelijk actief zijn (Free Plan 1 actief). Als alle sporen bezet zijn, dan moet de rest achteraan aansluiten.

Dergelijke vertragingen zijn in Invantive Bridge Online Monitoring te zien onder de kopjes, waarbij “Maximale Gelijktijdigheid” betrekking heeft op de 4 beschikbare sporen:

  • Vertraging op Maximale Gelijktijdigheid
  • Vertraging op Identieke Verzoeken
  • Vertraging bij mislukte aanmelding

Advies is om hetzij ook de andere downloads te versnellen, hetzij om minder downloads parallel te starten zoals beschreven in Parallel laden uitzetten in Power BI.

Advies 3: probleem PowerBI.com

Zoals eerder beschreven meten we sinds enige tijd op PowerBI.com dat ondanks hoge time-outwaardes er toch incidenteel OData downloads afgebroken worden na 5 minuten (plus/min enkele seconden). Ook worden deze afgebroken downloads niet opnieuw geprobeerd, zoals de reguliere OData-downloads wel tot vervelens toe honderden keren opnieuw geprobeerd worden. Dit probleem treedt ook niet bij Power BI Desktop, Power Query of Azure Data Factory.

De hypothese is dat er sprake is van een incidenteel optredende bug op PowerBI.com, waarbij downloads na 5 minuten definitief afgebroken worden. We zijn op dit moment bezig om met de boven beschreven nieuwe views een reproductiescenario te proberen krijgen om dit als bug bij Microsoft te kunnen indienen.

Advies is daarom om in afwachting van een reproductiescenario en oplossing (als inderdaad PowerBI.com bug is) de specifieke download te herhalen.

Een identiek probleem is tot dusver maar op 1 plek teruggevonden:

Ook deze gebruiker kreeg ondanks een time-out van 30 minuten al na 5 minuten een time-out op PowerBI.com.

Waar vind ik documentatie over het WEL en NIET gebruiken van de juiste API’s. M.a.w. hoe kon ik vermijden dat ik de tabel ReportingBalance heb gebruikt i.p.v. BalanceLinesPerPeriodCostAnalysis?

Is het niet beter dat jullie zware API’s niet toegankelijk maken voor eindgebruikers? En enkel de snelwerkende ter beschikking stellen?

De keuze van de juiste tabellen is helaas niet zwart/wit, bijvoorbeeld omdat sommige filters wel of niet werken of dat velden ontbreken. Een algemene richtlijn is te lezen op onder de twee kopjes met “Popular Tables” op:

Daarnaast wordt gedurende het uur introductie op basis van de dan geldende rapportagewensen meestal een globaal advies gegeven.

Het is mogelijk dat er in de nabije toekomst een optie komt om maar een selectie van de tabellen beschikbaar te stellen, maar dat is nog niet zeker omdat de 20.000 gekoppelde bedrijven nogal uiteenlopende gebruiksscenario’s kennen. We willen voorkomen dat er weer meer opties bijkomen die niet goed te begrijpen zijn.

Hoe komt het dat wij iedere week opnieuw foutmeldingen krijgen? Het gaat om een Power BI rapport van slechts 1.888 kB. De queries zijn optimaal opgemaakt, maar steeds opnieuw krijgen wij interne server errors of time out errors.

Processing error: Microsoft.Mashup.Engine1.Library.Resources.HttpResource: Request failed: OData Version: 4, Error: The remote server returned an error: (500) Internal Server Error. (Systeemfout. (itgenemd054, 2ee9fdcc-8d80-4769-9e4b-f202fdae9a51)) OData Version: 3, Error: The remote server returned an error: (500) Internal Server Error. (Systeemfout. (itgenemd054, 3b5484fa-6deb-495e-9e94-9f5a181d1a97))

Zie Error itgenboe147 ook na optimaliseren queries voor Exact Online PurchaseOrderLines - #7 door forums.

De oorzaak is onbekend.

De time-out na 5 minuten is een PowerBI.com-specifiek probleem waar we Microsoft nog geen reproductiescenario voor kunnen aanleveren. Er loopt een doorlopend traject om het probleem opgewekt te krijgen, maar tot dusver lukt het niet om PowerBI.com de time-out na 5 minuten te laten geven.

Het probleem treedt uitsluitend op bij gebruik van PowerBI.com; Power BI Desktop, Power Query en Azure Data Factory kennen het probleem niet.

De time-out na 5 minuten treedt incidenteel op; het is nog onduidelijk waarom de problemen vooral bij een zeer beperkt aantal accounts frequent optreedt.

Een analyse over de periode vanaf 24 maart 2022 geeft aan dat het probleem dagelijks in 3 promille van de OData downloads optrad bij circa 5% van de gebruikers. Beide aantallen begonnen sinds 10 april te verminderen om sinds 14 april nog dagelijks maar bij 1 tot 3 gebruikers op te treden bij enkele downloads.

Voor de itgenemd054 melding zie Interne serverfout itgenemd054.