OData: Request failed: The operation has timed out

Ik heb gisteren de licentievorm aangepast van Pro naar PPU (Power BI Premium per User, proefversie), en vanochtend is de refresh goed gegaan, zonder timeout error.

Dat kan natuurlijk toeval zijn, dus ik ga het in de komende dagen in de gaten houden.

Timeout-advies van @forums in de M Query is overigens ook nog het proberen waard.

1 Like

Een bericht is gesplitst naar een nieuw topic: Itgenscr652 melding bij dashboard bijwerken

Ik heb de afgelopen dagen even wat testen gedaan met een klant waar de dagelijkse load via Azure Data Factory vaak fout gaat.

Ik laad transactionlines 2021 en 2022 sequentieel op onderstaande manier:

ExactOnlineREST.Incremental.TransactionLinesIncremental@eol?$filter=FinancialYear eq 2021

Als ik dit om 5:00 's nachts doet gaat het bijna altijd fout na precies 20 minuten met de volgende melding:

ErrorCode=ODataRequestTimeout,'Type=Microsoft.DataTransfer.Common.Shared.HybridDeliveryException,Message=Fail to get response from odata service in a expected time.

Doe ik dit om 21:00 's avonds dan worden de aanvragen binnen 15 minuten afgerond en gaat het dus goed.

Om 5:00 's nachts duurt het dus langer, te lang. Ik kan alleen in ADF nergens een 20 minuten timeout vinden. Ik heb wel een Request Timeout, maar die staat (volgens mij) op 5 minuten:

Of komt die 20 minuten bij Invantive vandaan?

Dat is eigenaardig.

Nee, er is geen bekende limiet van 20 minuten. Met Invantive Bridge Online Monitoring bewaken we centraal alle omgevingen en vooral op platformen die veel punt-queries nodig hebben zijn er responsetijden van uren. Dit is een voorbeeld van de momenteel langstlopende OData query die er anderhalf uur over deed:

Vaak is het Loket of Teamleader door de punt-queries, maar in dit geval een optimalisatiemogelijkheid voor TransactionLines naar TransactionLinesIncremental.

Dit is een voorbeeld - mogelijkerwijs van de omgeving die je bedoelt - die er ruim 40 minuten over doet voor 460K rijen en ruim 500 MB download:

Het daadwerkelijk verwerkte volume zal enkele malen groter zijn, zie het filter op jaar. De incrementele tabellen vereisen dat alle jaren ontsleuteld en de nieuwe versie versleuteld worden.

Het eigenaardige is dat er voor ons geen enkele request te zien is die door een time out is afgebroken. Er zijn enkel een tiental Simplicate queries die faalden door delegatie en een reeks van queries die faalden door de Exact Online token issues met een gecontroleerde fout.

In het recente verleden hebben we wel gezien dat Power BI Service regelmatig crasht na het volledig ophalen van de data en dan blindelings opnieuw probeert. Dit gedrag met redelijk ongecontroleerd opnieuw proberen zien we ook vanuit Microsoft Power BI Desktop.

Via Google vind ik zo vlot over ADF en 20 minuten timeout de volgende link, maar ik weet niet of dit relevant is:

https://social.msdn.microsoft.com/Forums/azure/en-US/7b7ea6c1-1d23-4bc9-9c44-be69c6aa283c/premature-timeout-during-adf-copy-activity?forum=AzureDataFactory

De enige hit bij zoeken op “Fail to get response from odata service in a expected time” verwijst naar deze forums:

Het bleek in die case dat per abuis enkele duizenden administraties ingelezen werden via ADF van een langzame tabel en daardoor liep het erg lang. Maar ook hier was er een timeout van 20 minuten. Echter, anders dan bij een *Incremental tabel zal bij de daar gebruikte tabel de datastroom al na enkele seconden op gang komen. Bij een *Incremental tabel kan het minuten duren totdat de eerste rijen terugkomen in een grote omgeving omdat eerst de data geactualiseerd moet zijn.

Ook apart is de tekst van de foutmelding:

Fail to get response from odata service in a expected time

Door de talrijke taalfouten valt te gokken dat dit niet door een native English speaker geschreven is en ook door te weinig kwaliteitscontroles gegaan is om het te corrigeren. Microsoft heeft meestal zijn zaakjes wel op orde qua vertalingen en teksten. Het lijkt een obscure melding, zeker omdat hij op Google nergens te vinden is. Voor de zekerheid is bij ons alle broncode doorzocht hierop, maar hierin komt de melding niet voor. Hij werkt echter sowieso in zoverre af dat de kans erg klein was dat het uit Invantive code komt; alle code wordt op dit soort taalfouten gecontroleerd en bijvoorbeeld “odata” herschreven in “OData”.

Vraag 1: is het mogelijk om een screenshot van de ADF Copy Activity toe te voegen van de andere tabbladen, in het bijzonder “General”?

Vraag 2: is het mogelijk om de Request timeout van 5 minuten fors te verhogen naar bijvoorbeeld 02:00:00 (2 uur)?

Vraag 3: is het mogelijk om de log van de Azure Copy Activity toe te voegen zoals beschreven op Session log in a Copy activity - Azure Data Factory | Microsoft Docs?

Uiteindelijk zullen problemen zoals deze met pre-emptive loading opgelost worden ten koste van het near real-time karakter.

even als reactie op bulk <-> sync/incremental. Ik gebruik in dit geval een filter op FinancialYear, is het dan misschien niet economischer om in de dit geval de bulk api te gebruiken ipv incremental? Sneller, en we voldoen aan de voorwaarde van Exact om een filter te gebruiken (mandatory filtering)?

Vraag 1;





image

Vraag2: ja bij deze ingesteld. Laten we het even een paar dagen afwachten.

Vraag3: is op korte termijn wat lastig door te voeren omdat ik (met beperkte rechten) op de Azure omgeving van de klant zit. die hebben ook nu nog geen Blob storage or Data Lake, dus dat zal dan allemaal eerst ingericht moeten worden.

Na een paar dagen draaien (vanaf 5-11-2021) kan ik constateren dat het verlengen van de timeout naar 2:00:00 (volgens mij 2 uur) wel werkt. Maar dat vervolgens het laden van de data ook wel erg lang duurt. Ergens tussen de 2 en 4 uur. Terwijl dit voorheen in ongeveer 20 minuten klaar was (of dus een timeout).
Op dit moment loopt de load nog die vannacht startte om 5:00… Het zijn in totaal zo’n 1 miljoen regels.

Zou in dit geval de Bulk api misschien sneller zijn?

Dank. Bulk is voor Exact zelf geen optie meer.

We kijken waar het door kan komen. Kun je de gebruikte OData URL (zonder database naam) zekerheidshalve hier toevoegen? Wanneer was laatste download?

Kun je ook delegatie (laten) geven aan mij?

Kan het zijn dat het om deze gaat? Het ophalen van 466K rijen met Exact Online boekingen duurde hier (niet uit cache) minder dan zes minuten.

Ja, dat is hem 100%, URL klopt en het aantal rijden ook! dus dit geeft aan dat deze data in 6 minuten. klaar stond? Of ook daadwerkelijk opgeleverd is aan ADF aan jullie kant?

OK, dank. De data is in zijn geheel na 6 minuten afgeleverd (eerste bytes eerder, laatste na 6 minuten) aan ADF. En die is blijkbaar ergens heel lang mee bezig geweest. Heb je onderliggende logging van ADF?

Ok, duidelijk. Dit moet dan te maken hebben met de Request Timeout setting die ik had gezet naar 2 uur. Niet logisch, maar het enige wat veranderd is.

Logging laat niet heel veel zien, althans niet wanneer en hoe de data precies binnenkomt.

Ik test even verder.

Er was een URL waar ik kon zien hoeveel regels Invantive Cloud aan het cachen is. Begrijp je wat ik bedoel, dat zit in niet de standaard portal volgens mij…

Wat Invantive Cloud voor de Power BI-kant momenteel cachet is te vinden in Bridge Online Monitoring; een vinkje bij Cached geeft aan dat het antwoord uit cache kwam. Daarnaast zijn er nog twee onderliggende cachelagen; voor incrementele tabellen zijn dat tabellen met midden in de naam *Incremental* zoals:

Maar misschien begrijp ik de vraag niet.

ja, die bedoelde ik, Bridge Online Monitoring; https://bridge-online.cloud/monitoring deze url dus.

Misschien domme vraag, maar waar precies pas ik dit aan:

Limiet Looptijd

De maximale loopduur van een query is verschillend. De standaard maximale loopduur van een OData feed is 10 minuten (zie documentatie OData.Feed). Per OData-feed kan de limiet gewijzigd worden in de Advanced Editor

Goede vraag. Dit is toegevoegd hierboven:

Waar zit de advanced editor / geavanceerde editor?

Update De “advanced editor” is in Power BI te vinden in het venster dat omhoogkomt bij keuze van “Gegevens transformeren” in het lint:

Gegevens transformeren in Power BI Desktop

Kies daarna voor “Geavanceerde editor” bij een query:

Loop partij te stoeien hier mee maar kom er niet uit:

let
    Bron = OData.Feed("https://bridge-online.cloud/koos-van-der-beek-exact-online/odata4", null, [Implementation="2.0"]),
    #"ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol_table" = Bron{[Name="ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol",Signature="table"]}[Data],
    #"Namen van kolommen gewijzigd" = Table.RenameColumns(#"ExactOnlineREST.Incremental.SalesInvoiceLinesIncremental@eol_table",{{"AmountFCExclVat", "Omzet"}}),
    #"Rijen gefilterd" = Table.SelectRows(#"Namen van kolommen gewijzigd", each [LineNumber] <> 0),
    #"Namen van kolommen gewijzigd1" = Table.RenameColumns(#"Rijen gefilterd",{{"Omzet", "Omzet2"}, {"AmountDC", "Omzet"}}),
    #"Kolommen verwijderd" = Table.RemoveColumns(#"Namen van kolommen gewijzigd1",{"SalesChannel"}),
    #"Namen van kolommen gewijzigd2" = Table.RenameColumns(#"Kolommen verwijderd",{{"Omzet2", "Factuuromzet Excl.btw"}, {"Omzet", "Artikel Excl."}}),
    #"Rijen gefilterd2" = Table.SelectRows(#"Namen van kolommen gewijzigd2", each ([Division] = 874846))
in
    #"Rijen gefilterd2"

Dit staat er nu, maar lukt me niet om dit toe te voegen:

let
    Bron = OData.Feed(
"https://bridge-online.cloud/3279/odata4/", null, [Implementation="2.0", Timeout=#duration(0,2,0,0)]),    
#"Teamleader.V2.Projects@tlr_table" = Bron{[Name="Teamleader.V2.Projects@tlr",Signature="table"]}[Data]
in    
#"Teamleader.V2.Projects@tlr_table"

Zou je me kunnen helpen? Deze codetaal ben ik totaal onbekend mee, sorry.

“Token Eof verwacht” is foutmelding…

De tabel met “Teamleader” in de naam was puur context. Om de maximale looptijd te verlengen hoeft alleen “duration” met een waarde toegevoegd te worden.

Dus oud:

let
    Bron = OData.Feed("https://bridge-online.cloud/acme-exact-online/odata4", null, [Implementation="2.0"]),

en nieuw:

let
    Bron = OData.Feed("https://bridge-online.cloud/acme-exact-online/odata4", null, [Implementation="2.0", Timeout=#duration(0,2,0,0)]),

Nog beter is toevoegen van weglaten ontbrekende waardes en bron toevoegen:

let
    Bron = OData.Feed("https://bridge-online.cloud/acme-exact-online/odata4", null, [Implementation="2.0", ODataVersion=4, OmitValues=ODataOmitValues.Nulls, Headers=[Referer = "change-to-your-unique-id-for-the-source" ], Timeout=#duration(0,2,0,0)]),

De getoonde code in de geavanceerde editor is de echte taal van Power BI: M. De rest is allemaal user interface en plaatjes.

De uitleg van deze “duration” is te vinden op #duration - PowerQuery M | Microsoft Docs.

Een stukje M-bagage helpt om de meeste Power BI-issues te adresseren. Een goed startpunt is altijd Google, maar ook bijvoorbeeld deze tekst:

M heeft een heleboel aspecten vergelijkbaar met Invantive SQL, Lambda en R.

2 uur in de 'duration" gezet voor alle tabellen, ging 1 dag goed, nu blijft hij Time Out errors geven. Ik weet het niet meer…

In de recente Bridge Online Monitoring zijn geen langlopende jobs te zien, maar alle downloads kwamen uit cache, dus dat zegt weinig. De performance lijkt goed; een download van ver boven de miljoen boekingen was 1x zelfs in minder dan 9 seconden opgelepeld.

Het dagelijks verwerken van een volume van tussen de 1 en 2 miljoen transactieregels kan nog binnen Invantive Cloud, maar vereist wel enige aandacht en tijd om het goed te laten werken. De technische limiet voor Invantive Cloud zien we zelf rond de 10 miljoen boekingsregels op dit moment (kan over paar maanden weer anders zijn), maar dat volume in 1 administratie vereist wel veel aandacht en kennis om het goed op te zetten. Voor volumes boven de 10 miljoen boekingsregels raden we de on-premises producten aan.

Mocht je kunnen aanvullen met de details van een specifiek request uit Bridge Online Monitoring: graag.

Een aantal opties zijn: