Sinds een paar dagen krijg ik in Power BI een foutmelding itgenboe147 bij het herladen van het dashboard. Ik wilde in dit bericht meer info plaatsen, maar Bridge Online kan ik een aantal uren al niet meer openen.
De OData query time-out heb ik al eens veranderd, zoals beschreven in Vermijd time-out fout bij Power BI OData download - invantive. Het is een lange tijd goed gegaan, maar nu krijg ik telkens bij het herladen weer deze foutmelding.
De foutcode lijkt nu gewijzigd te zijn. Ik zie nu itgenboe161 als foutcode, waar ik al eerder mee kampte (Itgenboe161/ itgenboe241 - De gegevensdownload werd geannuleerd na).
Ik kom weer in Bridge Online:
met melding:
itgenboe161
De gegevensdownload werd geannuleerd na 5 minuten, 0 seconden, waarschijnlijk door de gebruiker.
De curl geeft ook een foutmelding:
curl: (35) schannel: next InitializeSecurityContext failed: CRYPT_E_REVOCATION_OFFLINE (0x80092013) - De intrekkingsfunctie kan het intrekken niet controleren omdat de intrekkingsserver offline is.
Ik hoor graag of hier al een update over is.
Årsagen til meldingen fra curl vil sandsynligvis ligge lokalt; rådet er at prøve en anden pc.
itgenboe161 efter 5 minutter, anden gang 7 minutterHTTP 499-fejlen med itgenboe161 ser ved gentest ud til at opstå ved 900.171 rækker (7 minutter, 16 sekunder) og optræder også fra Power BI Desktop via forespørgslen:
select t.*
from ExactOnlineREST.Incremental.TransactionLinesIncremental@eol t
URL’en er:
/acme-exact/odata4/ExactOnlineREST.Incremental.TransactionLinesIncremental@eol
Et testmiljø er blevet opsat, hvorefter det er blevet undersøgt igen med mere logning via request-ID 0HNBGI0ODU7QM:00000001. Her viste det sig, at der efter 900.171 rækker på 4 minutter begyndes på en anden administration med divisionskode 3077666. Herfra hentes der cirka 2,011 millioner rækker, før der modtages en anmodning om at annullere downloadet ifølge softwaren på transaktion ec4646d02522b929:
Det forventede antal rækker pr. division er baseret på itgeneor778:
| Division | Antal |
|---|---|
| 3077666 | 2.168.201 |
| 3101321 | 242 |
| 3101317 | 3.873 |
| 3138257 | 278 |
| 3138285 | 1.497 |
| 3138305 | 4.114 |
| 3157850 | 8.176 |
| 3258681 | 1.261 |
| 3302180 | 168 |
| 3374315 | 872.891 |
| 3374318 | 6.429 |
| 3374321 | 1.242 |
| I alt | 3.068.372 |
| I alt undtagen den største | 900.171 |
Tilsyneladende bliver alle administrationer undtagen den allerstørste behandlet inden for 4 minutter. Den allerstørste når dog kun op på 2.011.000 rækker, før anmodningen annulleres kl. 2025-03-31T20:22:21,7981143Z, hvorved de sidste 157.201 rækker ikke bliver hentet.
Den sidste aktivitet på den næststørste division, 3374315, finder sted kl. 2025-03-31T20:17:18,3417795.
Det er bemærkelsesværdigt, at den sidste aktivitet for 3374315 finder sted 5 minutter og 3 sekunder, før den største stopper for tidligt.
Det ser ud til, at Power BI Desktop beslutter at annullere downloadet, hvis der ikke er kommet en eneste række i 5 minutter. Denne annulleringsanmodning bliver fanget af Invantive Bridge Online og pænt omsat til den ønskede adfærd: et afbrudt download.
Bemærk, at ikke alle afbrudte downloads hænger sammen med dette: også et vilkårligt andet download, der kørte længere end 5 minutter, kan være blevet afbrudt, fordi der ikke blev sendt en eneste række i 5 minutter.
Meget sammenlignelige problemer er:
Det er desværre ikke lykkedes en eneste gang at få dette problem til at optræde reproducerbart. Det er dog tilfældet med dette problem.
Et lignende problem (men uden løsning) på Microsoft-communityet er:
Opsummering: hvis der ikke er blevet transporteret rækker i 5 minutter (som ofte er tilfældet ved store inkrementelle tabeller), vil Power BI Desktop afbryde downloadet.
Når det drejer sig om 500.000 rækker eller mere, forekommer en itgenboe147 eller itgenboe161 undertiden, fordi en standard Power BI Professional-plan ikke tilbyder tilstrækkelig kapacitet til dette. Download med Power BI Desktop fungerer dog fint.
Prøv ved større antal rækker et mere udvidet abonnement hos Microsoft, såsom Power BI Premium per User. Dette giver som regel afhjælpning op til et par millioner rækker.
Over et par millioner rækker anbefales det at overveje brug af f.eks. Azure Data Factory eller filtrering.
En mulig historisk fejl i Microsoft OData-klienten, som hænger sammen med dette, er:
hvor ReadWriteTimeout kan indstilles:
so we check if the user set this value, if they did not set it then it is zero. If the user set the value then the
HttpWebRequestuses that value. Otherwise it uses its default value which is 300 seconds for theReadWriteTimeoutproperty.
og
timeout is the number of milliseconds to wait before the request(basically the connection) timesout while readWriteTimeout is the number of milliseconds to wait before the writing/reading of a request/response timeouts.
hvor der er foretaget en ændring i src/Microsoft.OData.Client/ODataRequestMessageWrapper.cs, som findes på odata.net/src/Microsoft.OData.Client/ODataRequestMessageWrapper.cs at 01d32a4f8c892eb3f6aa4e1d6715b51dbd2196ce · ElizabethOkerio/odata.net · GitHub.
Her gøres følgende kode mulig siden 2020:
if (requestInfo.ReadWriteTimeout != 0)
{
requestMessage.ReadWriteTimeout = requestInfo.ReadWriteTimeout;
}
Denne kaldes af ODataMessageWritingHelper.cs. Der blev dengang ikke truffet nogen foranstaltning for dette inden for Power BI.
I 2024 blev logikken flyttet til et lavereliggende bibliotek på grund af den mere intensive brug af .NET Core i stedet for .NET Framework. Heller ikke da blev der truffet foranstaltninger til at indstille ReadWriteTimeout på en HTTP-forespørgsel, hvorfor standardværdien altid forbliver 5 minutter, som beskrevet på HttpWebRequest.ReadWriteTimeout Property (System.Net) | Microsoft Learn. Det vides ikke, om Power Query på Mac Excel, som bruger HttpClient, har gavn af eller er påvirket af dette, da egenskaben er udgået i HttpClient.
Der er heller ikke fundet nogen udokumenteret funktion til dette:
Opsummering: Microsoft OData-biblioteket, som Power BI bruger, har en standardværdi på 5 minutter for ReadWriteTimeout. Denne indstilling kan ikke ændres.
Problemet vil blive drøftet yderligere internt hos Invantive. Mulige løsningsretninger beskrives her.
Den ideelle løsningsretning er at få begrænsningen/fejlen i OData-feedet løst. Baseret på erfaringer med andre problemer i Power BI er forventningen dog ikke, at en sådan fejl vil blive løst og udrullet inden for tre år efter indrapportering.
En anden protokol (TDS) er under udvikling (se Topics tagged invantive-universalsql-server). Det er muligt, at Power BI-driveren ikke giver en fejlmelding for denne.
Generelt vil et efterfølgende indlæsningsforsøg kunne hente mere data fra HTTP-cachene. Dette forklarer sandsynligvis også det relativt begrænsede antal problemer, der opstår i forbindelse med dette, samt det faktum, at der som regel er flere store administrationer.
Følgende grove målinger er foretaget uden kalibrering og uden gentagne målinger:
Under forudsætning af, at hentningen af de cirka 2,2 millioner bogføringslinjer fra den største administration først begynder, efter at de andre 900.000 allerede er hentet, vil den realistisk forventede maksimale downloadvarighed være 2200 sekunder, hvis alle caches er tomme.
Med fuldt fyldte caches er den minimale downloadvarighed 183 sekunder.
Den maksimale datasætstørrelse konvergerer ved et uendeligt antal downloadforsøg mod cirka 2,95 millioner rækker. Dette stemmer overens med tidligere erfaringer med større administrationer, der blev behandlet via Invantive Cloud i stedet for via Data Hub.
Tallene varierer en smule afhængigt af, om det er Exact Online SaaS eller Exact Online Premium.
Bemærk, at meget højere antal er mulige, hvis der er flere administrationer tilgængelige og fortsat tilgængelige til at indlæse fra, som det er tilfældet i store regnskabsmiljøer.
Med udgangspunkt i 2,2 millioner rækker vil der være behov for mindst 10 downloadforsøg for at omgå ReadWriteTimeout på 300 sekunder, og ud fra de nedenfor viste gennemstrømningshastigheder:
Scenariet ser værre ud, hvis datasættene fra Exact Online skal indlæses igen. Lejlighedsvis stemmer tallene fra Exact Online ikke, og alt skal indlæses igen.
En mulig løsningsretning kunne være at give en række tilbage en gang imellem, så længe indsamlingen af data er aktiv. Dette kan gøres ved at bruge et API, der er pagineret, eller ved at læse flere partitioner/administrationer samtidigt.
Dog har specifikt de inkrementelle tabeller i Exact Online og Freshdesk den egenskab, at de først kan returnere rækker efter fuldstændig bestemmelse. Tidligere kunne dette i princippet ske tidligere, men på grund af nødvendige workarounds for fejl/begrænsninger i Power Query-implementeringen i Excel er dette i øjeblikket ikke længere enkelt at realisere.
Og tilsyneladende forekommer også kombinationen, at 1 specifik administration er mindst 300 x 1250 rækker = 375.000 rækker større end alle de andre, hvorved der i praksis mindst 1 gang kan forekomme en timeout efter 5 minutter, og oftere hvis datasættet er større.
Mulige løsningsretninger er for eksempel:
Ved at øge hastigheden forskydes grænsen bagud:
skiptoken for at opnå en højere gennemstrømningshastighed end 75 kald pr. minut.ReadWriteTimeout videresendes til NetworkStream. Der findes dog ingen faciliteter til at sende et heartbeat, ping eller out-of-band-besked.
Filteret undgår et antal rækker. Det er muligt løbende at returnere “falske rækker”, som bliver filtreret fra client-side af Power BI.
Indsamlingen af data til en inkrementel tabel foregår i sekventielle trin. Da de indledende trin tager stadig længere tid på grund af det voksende antal rækker, der allerede er behandlet, vil der gå mere og mere tid tabt hertil. Det er muligvis muligt at behandle dele samtidigt, så hentningen af data fra Exact Online API’en starter så gnidningsfrit som muligt, og antallet af forsøg begrænses. Det maksimale antal rækker, som nu er 2,8 millioner rækker for 1 administration inden for 5 minutter, vil da kunne stige til en betydeligt højere værdi efter et antal forsøg.
Indsamlingen af data til en inkrementel tabel foregår i sekventielle trin. Da de indledende trin tager stadig længere tid på grund af det voksende antal rækker, der allerede er behandlet, vil der gå mere og mere tid tabt hertil. Det er muligvis muligt at optimere de indledende trin med hensyn til ydeevne. Det maksimale antal rækker, som nu er 2,8 millioner rækker for 1 administration inden for 5 minutter, vil da kunne stige til en betydeligt højere værdi efter et antal forsøg.
Antallet af rækker er allerede kendt på forhånd, som det fremgår af flowdiagrammet.
Eventuelt kan antallet af partitioner, der behandles samtidigt for et datasæt, begrænses, så f.eks. det mindste datasæt kører længst med en minimal gennemstrømningshastighed.
Dette ligner dryppet, men i stedet er det brugeren selv, der sænker den udgående gennemstrømningshastighed, f.eks. via driverattributten requests-max-parallel.
Problemet forekommer kun i Power BI og Power Query på grund af overtagelsen af standardnetværksindstillingerne uden at tilbyde en konfigurationsmulighed for dette.
Ved at bruge curl eller kode i et programmeringssprog med de rigtige indstillinger kan cachene indlæses. For optimal ydeevne skal indstillingerne vedrørende komprimering (gzip, Brotli, ingen) være således, at også result set-cachen kan bruges.
De API-limieten van Exact Online Premium worden of zijn schijnbaar verlaagd: waar die voorheen 300 API-calls per minuut waren worden dat maximaal 60 API-calls tenzij men bijbetaalt.
Ook het maximaal aantal API-calls per dag wordt verlaagd voor Exact Online Premium voor hetzelfde bedrag. Ook voor Exact Online SaaS worden de API-calls verregaand verlaagd door op abonnementsniveau te gaan tellen (dus over administraties heen). Voor het gebruik van de XML API worden de limieten een factor 50 verlaagd.
Zie voor meer details:
Uit onderzoekt blijkt dat de oude limiet van 300 API-calls gehandhaafd wordt voor apps waar men reeds met een Exact Online Premium-omgeving verbinding heeft gehad. Voor nieuwe apps die geautoriseerd worden, wordt blijkbaar weer een van 60 API-calls per minuut gehanteerd, tenzij men een upgrade afneemt.
De limiet van 30.000 API-calls lijkt zowel voor recent als vroeger gekoppelde apps gehanteerd te worden.
In de volgende release van Invantive UniversalSQL zal een eventueel hogere Exact Online-minuutlimiet gebruikt worden, maar nieuwe Exact Online-gebruikers zullen hiervan geen profijt hebben tenzij ze eerder met Invantive Cloud gekoppeld hebben.
De resterende volgende oplossingsrichtingen (buiten de workarounds die een gebruiker kan maken) zijn:
Na een kleine twee weken gewerkt te hebben, krijg ik opnieuw de foutmelding. Meerdere genoemde oplossingen geprobeerd, maar tevergeefs. Daarnaast heb tijdens testen geregeld foutmelding 503 in Power BI gekregen dat de gateway niet beschikbaar is. Deze melding is tegelijkertijd te zien in Bridge Online.
Is er al een update om deze error permanent te verhelpen?
Een aantal verbeteringen zijn doorgevoerd om deze problemen op te heffen.
Deze vraag is automatisch gesloten na 1 week inactiviteit. Het laatste gegeven antwoord is gemarkeerd als oplossing.
Gelieve een nieuwe vraag te stellen via een apart topic als het probleem opnieuw optreedt. Gelieve in de nieuwe vraag een link naar dit topic op te nemen door de URL er van in de tekst te plakken.