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.
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:
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:
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)?
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)?
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?
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?
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:
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…
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.
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.
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:
Controleer de Power BI abonnementsvorm en wissel eventueel naar PPU (Power BI Premium per User).