Error itgenboe147 ook na optimaliseren queries voor Exact Online PurchaseOrderLines

Vragen
, , ,
1

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 https://go.invantive.com/en/power-bi-tuning. 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)

2

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.
3

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.
4

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?

5

Schermafbeelding 2022-05-02 141247
Schermafbeelding 2022-05-02 1412471500×345 33.9 KB

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

6

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.

7

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.

8

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?

9

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.

10

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))
11

Schermafbeelding 2022-05-09 094146
Schermafbeelding 2022-05-09 094146742×190 15 KB

12

Zie Error itgenboe147 ook na optimaliseren queries voor Exact Online PurchaseOrderLines - 7 van 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.

13

Voor de itgenemd054 melding zie Interne serverfout itgenemd054.

14

De time-out van 5 minuten hebben we nog geen reproductiescenario voor kunnen opstellen. Verdere tests lopen nog.

15

Enkele gebruikers hebben er ook last van. Inmiddels hebben we ook 1x een vrijwel identiek probleem bij het gebruik van de Invantive Bridge Online driver vanuit Invantive Data Hub om verbinding te leggen met Invantive Bridge Online.

Hierbij wordt een tabel StockPositions gebruikt, maar na 5 minuten zijn er nog geen rijen opgehaald.

image
image1254×467 75 KB

Bijzonder is dat er na 5 minuten nog geen rijen opgehaald waren:

Tijdstip Code Onderdeel Tekst
10-06-2022 21:17:26.797 itgenire041 ResponseCache Verzoek verwerkt. De metagegevens van de responscache zijn niet bijgewerkt omdat ten minste enkele schrijfacties zijn mislukt.
10-06-2022 21:17:26.796 itgenire045 ResponseCache Het ophalen van het niet-gecachete antwoord is mislukt. Retourneer mislukte antwoord. Voeg geen mislukte respons toe aan de responscache.
10-06-2022 21:17:26.795 itgenboe313 Monitoring Het downloaden van de gegevens werd na 5 minuten geannuleerd, bijvoorbeeld doordat de gebruiker in een browser wegnavigeerde. Optimaliseer uw query zoals beschreven op https://go.invantive.com/nl/power-bi-tuning. Voer de query vervolgens opnieuw uit. (/solidus-solutions-group-exact-online/odata4/ExactOnlineXML.XML.StockPositions@eol).
10-06-2022 21:17:26.782 itgeniee011 Toepassinguitzondering itgenpmr003: The execution was cancelled.
10-06-2022 21:17:26.738 itgenboe237 DataRetrieval Ophalen van het logboek is mislukt. Tot nu toe 0 rijen opgehaald uit ‘ExactOnlineXML.XML.StockPositions’ in 279,434 ms.
10-06-2022 21:12:47.306 itgenboe154 DataRetrieval Begin met gegevens opleveren.
10-06-2022 21:12:47.295 itgenboe150 DataRetrieval Het gegenereerde SQL-statement is: select t.* from ExactOnlineXML.XML.StockPositions@eol t

In dit geval worden voor twee administraties de gegevens opgehaald bij Exact Online. Uit de logging lijkt dat een Exact Online API-download gestart wordt. In de daarop volgende 5 minuten komt geen antwoord door de Exact Online API-server en worden 0 rijen teruggestuurd.

Het verzoek wordt na 5 minuten beëindigd. Het is nog niet duidelijk of dat komt doordat PowerBI.com beslist dat door gebrek aan retourdata de verbinding beëindigd kan worden of dat dat geïnitieerd wordt door een onderdeel van de Invantive SQL engine.

Het is in ieder geval onwenselijk dat er 5 minuten gewacht wordt totdat Exact Online een antwoord geeft en dat maar 1x geprobeerd wordt. Dit probleem is enigszins gelijkend op Itgenoda055: HTTP 408 Request Timeout errors op Exact Online dat sinds mei 2021 optreedt. Hierover is niks bekend, behalve dat het incidenteel gebeurt en lijkt samen te hangen met de introductie van een nieuwe infrastructuurcomponent bij Exact Online.

Verder onderzoek zal uitgevoerd worden en dit topic bijgewerkt.

16

Meer signalen zijn gemeten dat er ieder geval een probleem is op de Exact Online-API’s, waarbij binnen 5 minuten geen data terugkomt uit een geldige Exact Online API call en de keten de verwerking staakt.

Op geen van de andere platformen is deze melding geregistreerd in de onderzochte periode van de afgelopen 4 weken. Hierbij wordt gezocht naar het voorkomen van itgenhbr048; een time-out op een tekst-download (JSON of eventueel XML).

Het probleem treedt op in zowel Belgische als Nederlandse administraties en het lijkt niet samen te hangen met welke Exact Online API tabel of API-variant; het probleem wordt gezien bij projecten, salaris, handel, financieel, XML, abonnementen en productie. Mogelijkerwijs dat er inderdaad een relatie is met een generiek probleem op Exact Online. Het probleem met het ontvangen van een antwoord treedt incidenteel op, soms rond 2 uur UTC, maar ook vaak in de Nederlandse ochtend, middag en avond.

Het probleem is geen enkele keer opgetreden met binaire downloads, dus mogelijkerwijs is er sprake van een netwerkcomponent bij Exact Online die alleen gebruikt wordt voor tekst-gebaseerde API’s (JSON of eventueel XML).

Een aantal aanscherping van de time-out zullen in de volgende release verwerkt worden. Hiermee zal het probleem niet weg zijn of minder frequent optreden, maar de problematiek zal hiermee scherper duidelijk worden. Ook zal minder lang gewacht worden in geval van falen om een antwoord terug te krijgen, zodat de responsiveness van Invantive SQL beter wordt.

In de volgende release zal dan op basis van de aangescherpte probleemduiding een betere of duidelijker afhandeling van een time-out op Exact Online mogelijk worden.

17

Een omvangrijke wijziging van Invantive Cloud is in productie genomen. Onderdeel van deze wijziging is dat time-outs op de Exact Online API een andere wijze opnieuw geprobeerd worden. Ook worden time-outs eerder als een time-out beschouwd; niet meer soms pas na 5 minuten, maar na bijvoorbeeld 30 seconden (afhankelijk van de instellingen). Hierdoor is de kans groter dat een query een acceptabele looptijd heeft.

Connectiviteitsproblemen die resteren na deze gewijzigde logica worden niet meer onterecht als afkomstig van een gebruikersactie getoond. Dit was bijzonder verwarrend.

In deze release zit ook onder andere functionaliteit voor Exact Online Premium, de YouTrack SQL en Power BI driver en grote delen van de Italiaanstalige versie.

Het betreft meerdere ingrijpende wijzigingen. Indien er nieuwe stabiliteitsproblemen ontstaan gaarne een aanvulling onder dit bericht.

Indien het itgenboe147 probleem blijvend opgelost is met verwachte resultaten of juist niet: gaarne een aanvulling.

18

Query blijft uitvallen na 5 minuten ondanks ruime time-out. Ik hoop dat de oorzaak snel bekend en opgelost is.

OData.Feed(BaseURL + ExactOnlineREST.Incremental.TransactionLinesIncremental@eol
, null, [Implementation = “2.0”,ODataVersion=4,OmitValues=ODataOmitValues.Nulls,Timeout=#duration(0,2,0,0)])

19

Is het mogelijk als antwoord een screenshot (geanonimiseerd) toe te voegen van een request op Bridge Online Monitoring dat na 5 minuten afgebroken is?

Gelieve de hexadecimale waarde bovenaan in de blauwe titelbalk niet weg te halen.

20

Indien de itgenboe147 of andere time-out na 5 minuten plus/minus enkele second optreedt, dan is op 8 augustus 2022 een versie van Invantive Cloud in productie genomen die dit probleem oplost. Zie Hoe los ik een itgenboe147 of itgenboe161 melding op: The data download was geannuleerd / cancelled voor meer informatie.