OData: Request failed: The operation has timed out

Wanneer ik in PowerBI online gegevens probeer te vernieuwen krijg ik voortaan altijd een time-out melding of een “underlying connection was closed” melding. Ik kan dus ook niet instellen dat ie de gegevens dagelijks automatisch moet vernieuwen.

Waarom krijg ik deze melding? Is de hoeveelheid data te veel?

Element Waarde
Verwerkingsfout OData: Request failed: The operation has timed out
URI cluster WABI-WEST-EUROPE-D-PRIMARY-redirect.analysis.windows.net
Activiteits-id ec763aa3-b56b-4f21-8379-b19e8657f7b7
Aanvraag-id 76c06bba-1d4a-9a95-c9e5-7e91e202da3b
Tijd 2021-11-02 12:57:11Z

Of:

Element Waarde
Verwerkingsfout OData: Request failed: The underlying connection was closed: An unexpected error occurred on a receive.
URI cluster WABI-WEST-EUROPE-D-PRIMARY-redirect.analysis.windows.net
Activiteits-id ec763aa3-b56b-4f21-8379-b19e8657f7b7
Aanvraag-id 3cbd298f-c709-c03d-1a66-885c7489b1e7
Tijd 2021-11-02 12:47:09Z

Samenvatting

De onderstaande tekst is ook verwerkt in het samenvattingsartikel Vermijd time-out fout bij Power BI OData download.

Er is gisteren nog 1 andere vrijwel identieke melding geweest van een gebruiker over een “request failed” error waarbij van de 20 keer verversen op Power BI Service de OData refresh maar 2 keer slaagt. Ook hier is de voornaamste foutmelding:

Aspect Waarde
Melding OData: Request failed: The operation has timed out
Start 1-11-2021 20:19:16
Einde 1-11-2021 21:13:08

Bijzonder is dat deze “request failed: The operation has timed out” error optreedt ruim voor middernacht. Zelfs met een tijdzoneverschil van 2 uur (het is niet duidelijk of de tijden in CET of UTC zijn) is dit ruim voor herstarttijden van bijvoorbeeld Exact Online API servers en langdurige patches. We kunnen daarom storingen op het achterliggende platform als oorzaak uitsluiten.

Vergelijkbare melding “Request failed: The operation has timed out”

De error “The operation has timed out” is sterk gelijkend op de Power BI problemen beschreven op Data laden vanuit OData (Bridge-Online) werkt niet meer. Toendertijd was het echter duidelijk te wijten aan een te zware belasting voor de Invantive Cloud-infrastructuur. Nu treedt het probleem - zoals ik begrijp uit reacties per e-mail - alleen op via PowerBI.com en niet bij verversen via Microsoft Power BI Desktop. We kunnen daarom de Invantive Cloud-infrastructuur daarom uitsluiten als oorzaak.

Limiet Data

Power BI en vooral Power BI Service (PowerBI.com) heeft een aantal limieten. De maximale hoogte is afhankelijk van de licentievorm, waarbij duurder niet altijd beter is. Denk bijvoorbeeld aan een 1 GB limiet op zowel gratis als Power BI Pro voor een datamodel van een PBIX waar omheen gewerkt kan worden door de dataset op te knippen in kleinere.

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, zoals met:

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"

De cruciale en enige benodigde aanpassing is het aanpassen van de regel:

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

in

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

Hierdoor zal er twee uur i.p.v. 10 minuten gewacht worden.

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:

Tijdsduur

In dit voorbeeld geeft #duration(0, 1, 50, 40) een (arbitrair gekozen) tijdsduur weer van 1 uur, 50 minuten en 40 seconden. De syntax van #duration is online te vinden in de Power Query M documentatie.

De maximaal limiet voor een OData feed is voor Power BI Pro 120 minuten en voor Premium 300 minuten (documentatie).

Er is bij mij op dit moment geen manier bekend om de timeout centraal in te stellen op de OData-bron zoals dat wel kan met sommige andere bronnen via “data source settings”.

Merk op dat voor dataflows weer andere timeouts gelden (2 uur voor tabel, 3 uur voor dataflow, 24 uur met Premium).

Time-outs zijn sinds de beschikbaarheid van Power BI downloads vanuit Twinfield, Exact Online en anderen vlot afbreken ook terug te vinden in de Bridge Online Monitoring. Als PowerBI.com eenzijdig de download staakt, dan verschijnt een itgenpmr003 melding zoals in onderstaand voorbeeld waarbij na 10 minuten telkens de verbinding verbroken wordt:

Advies 1: controleer dat de OData dataset een timeout ingesteld heeft. Indien niet, stel die om te beginnen in op 120 minuten en pas die verder waar nodig aan.

Interne PowerBI.com Crashes

Een probleem dat gebruik van PowerBI.com soms in de weg staat is dat PowerBI.com op grote OData datasets nogal eens zelf crasht. De Power BI Service probeert dan rustig honderden keren opnieuw dezelfde OData dataset op te halen. Mogelijkerwijs wordt in de toekomst indien dit automatisch gedetecteerd wordt het gebruik automatisch kortstondig geblokkeerd om impact voor andere gebruikers te vermijden.

Vragen

Om verder een beter beeld te krijgen van de situatie:

  • Welk licentievorm op Power BI wordt gebruikt: gratis, Pro, Premium of Premium Generation 2?
  • Zijn er de afgelopen 30 dagen meldingen geweest vanuit Invantive om te wisselen van gebruikte tabel om de prestaties te verbeteren?
  • Wat is de exacte start- en eindtijd die bij de melding staat zodat de looptijd bepaald kan worden (een timeout treedt vaak op bij “ronde” aantallen minuten)?
  • Welke tabel / OData URL betreft het?
  • Hoeveel rijen zitten er grofweg in de OData dataset?
  • Hoeveel bytes netwerkomvang geeft Invantive Bridge Online Monitoring aan voor het verzoek? Door dit te vermenigvuldigen met 10 a 15 voor decompressie (afhankelijk van compressieprotocol) is een schatting van het te verwerken datavolume door PowerBI.com te krijgen. Een netwerkomvang van 500 MB is tot circa 7,5 GB voor verwerking binnen de 10 GB limiet voor gedeelde capaciteit. Een netwerkomvang van 500 MB is tot circa 750 MB binnen de limiet van 1 GB voor datasets in Power BI Service.

Advies 2: Vraag antwoord op bovenstaande vragen toe als een antwoord.

Advies 3: staat automatisch mailen van de gebruiker al aan als er een verversingsfout optreedt? Dit maakt het mogelijk om korter op de bal te spelen zodat de verzoekjes nog in Invantive Bridge Online Monitoring zichtbaar zijn.

Tip: Azure Data Factory

Sommige omgevingen op Invantive Cloud zijn groter dan anderen; soms met tot 1.000 administraties en soms zijn het gewoon erg veel gegevens of gebruikers. Bij intensief gebruik raden we aan om bijvoorbeeld Azure Data Factory te gebruiken om de gegevens vanuit Invantive Cloud in een database te laden en die te gebruiken; Azure Data Factory is net zoals Power BI onderdeel van Microsoft’s Azure cloudomgeving en staat daardoor veel dichterbij.

Tip: Pull-principe en Pre-emptive loading

Invantive Cloud maakt near real-time rapporten mogelijk dankzij het “pull”-principe. Anders dan veel andere oplossingen die op vaste tijden data klaarzetten (bijvoorbeeld 8 uur 's ochtends) worden de data pas opgehaald zodra ze aangevraagd worden. Dit is vergelijkbaar met asynchroon CPU’s ten opzichte van de regulier geklokte. Naast near real-time gedrag en hogere prestaties heeft dit ook dezelfde nadelen als deze speciale categorie van processoren:

  • Minder bekend en daardoor kost meer tijd om mee te leren werken: het push-principe met vaste tijden wordt al decennia gebruikt voor datawarehouses, pull is relatief nieuw.
  • Problemen in de keten (bijvoorbeeld een storing op het gekoppelde platform) zijn sneller zichtbaar omdat er met near real-time gegevens gewerkt wordt.

Voor punt 2 is om een gebruiker in staat te stellen om problemen in de keten tijdelijk te accepteren is recent een cache-only optie toegevoegd zoals beschreven op Cache only-modus voor Invantive Bridge Online: minder problemen als cloud-platform instabiel is.

Voor punt 1 (“onbekend maakt onbemind”) overwegen we een pre-emptive loading feature toe te voegen. Gebruikers kunnen dan per tabel aangeven dat ze die bijvoorbeeld 's ochtends al willen laten klaarzetten om een vaste tijd. Hiermee wordt dan het oude bekende push-principe weer toegevoegd.

Op dit moment kun je als gebruiker dit zelf ook realiseren: door in de ochtend een gelijktijdige dataset refresh te schedulen via de Power BI Service wordt effectief hetzelfde bereikt (zie Pre-load data in OData-cache to avoid Power BI timeouts). Gedurende levensduur van de Invantive Cloud-caches worden dan de gehele dag dezelfde gegevens gebruikt. Een timeout zal dan niet meer kunnen optreden omdat de data geleverd wordt uit de zeer snelle response cache.

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 Learn?

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:

https://documentation.invantive.com/2017R2/exact-online-data-model/webhelp/invantive-exact-online-connector-exactonlinedatadictionary-datadictionary-incrementalloadstatistics.html

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

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.