Probleem bij refreshen Visma.net JournalTransactionlines

Ik krijg sinds een tijdje een foutmelding bij de refresh van mijn rapportage gelinkt met Visma.net Financials. Het gaat volgens Power BI om de tabel JournalTransactionLines, maar Bridge Monitoring geeft aan dat deze gewoon succesvol is opgeleverd. Ook de refresh lokaal gaat zonder probleem, maar de online service refresh faalt binnen een minuut al.

De foutmelding is daarom alleen beschikbaar in Power BI Online, en deze helpt mij niet verder. Andere rapportages gekoppeld met Visma op deze manier lopen wel gewoon door.

Wat kan hier aan de hand zijn? Dank alvast!

{"error":{"code":"DM_GWPipeline_Gateway_MashupDataAccessError","pbi.error":{"code":"DM_GWPipeline_Gateway_MashupDataAccessError","parameters":{},"details":[{"code":"DM_ErrorDetailNameCode_UnderlyingErrorCode","detail":{"type":1,"value":"-2147467259"}},{"code":"DM_ErrorDetailNameCode_UnderlyingErrorMessage","detail":{"type":1,"value":"OData: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host."}},{"code":"DM_ErrorDetailNameCode_UnderlyingHResult","detail":{"type":1,"value":"-2147467259"}},{"code":"Microsoft.Data.Mashup.ValueError.DataSourceKind","detail":{"type":1,"value":"OData"}},{"code":"Microsoft.Data.Mashup.ValueError.DataSourcePath","detail":{"type":1,"value":"https://bridge-online.cloud/[**URL**]/odata4/VismaNet.Views.JournalTransactionLines@vnt"}},{"code":"Microsoft.Data.Mashup.ValueError.Reason","detail":{"type":1,"value":"DataSource.Error"}}],"exceptionCulprit":1}}} Table: JournalTransactionLines.

Hi, weet iemand misschien wat hier gebeurt?

Dit betreft een Power BI Service-only foutmelding. De essentie is:

OData: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host.

Aangezien het op andere Microsoft-platformen niet optreedt, lijkt dit bijzonder veel op de melding:

Advies is om:

  • Controleer dat het abonnement op basis van Microsoft Power BI Premium per User is, en niet Power BI Professional. Dit schijnt de limieten wat te verhogen.
  • Is het mogelijk om aan te geven om hoeveel rijen en MB het ongeveer gaat, bijvoorbeeld door een geanonimiseerde schermafdruk van zo’n geslaagd verzoek uit Bridge Online Monitoring toe te voegen?
  • Steun ons initiatief via https://ideas.fabric.microsoft.com/ideas/idea/?ideaid=b9362940-2e3e-ed11-97b0-281878deb618 om PowerBI.com te verbeteren.
  • Knip de download op in losse downloads met een filter, en voeg die samen, om om de Power BI Service-bug heen te werken.

Dank voor antwoord.

Het gaat om 1.2 miljoen rijen die ik in een query zet. Hiervan is ~1 miljoen gearchiveerd in een online Excel, en roep ik de overige 200k rijen op uit de OData koppeling. In Power Query voeg ik de resultaten samen. Wat dus echt via de OData koppeling terug komt is ongeveer 200.000 rijen.

Invantive geeft “succesvol” aan, maar de Power BI service geeft de foutmelding, maar wel alleen als het een refresh betreft die Invantive beantwoord uit de cache. Anders geeft Power BI wel succesvol aan.

Zie hieronder een nieuwe refresh request en één die uit de cache komt. De tweede gaat weer fout bij Power BI.

Het vermoeden is dat Power BI Service (PowerBI.com) crasht gedurende de verwerking. Dit is een patroon dat vaker waargenomen wordt. Vaak gaat dit gepaard met meerdere pogingen opnieuw om de data op te halen.

De inhoud van de response cache is 100% identiek aan het oorspronkelijke antwoord, maar dan met veel hogere snelheid aangeboden. Het is feitelijk een download met maximale lijnsnelheid (500 MB/s).

Advies is om dit punt bij Microsoft te melden. Voor Microsoft kan het probleem reproduceerbaar gemaakt worden door de download via curl op te halen op een file server met basic authenticatie, en dan probleem op te wekken.

Alternatieven:

  • Knip query op in meerdere queries om het probleem heenwerkt, telkens met een ander filter, zoals per periode binnen het jaar.
  • Geef ledger_number mee zoals “WERKELIJK” om het volume te beperken.
  • Kopieer de data eerst naar bijvoorbeeld SQL Server met bijvoorbeeld create or replace table naam@sql as select * from ... zoals beschreven in Elementaire datareplicatie tussen Exact Online en Azure SQL Server om zo de bug in PowerBI.com mogelijk te omzeilen.

Mocht het een grote omgeving zijn met veel bedrijven, dan is een aanpassing doorgevoerd om te zorgen dat de kans groter is dat het filter op COMPANY_CODE ook effect sorteert. Dit zal de download van bijna 1 uur sneller maken, maar lost bovengenoemd probleem niet op.

Deze vraag is automatisch gesloten na 2 weken 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.

Dit topic is 7 dagen na het laatste antwoord automatisch gesloten. Nieuwe antwoorden zijn niet meer toegestaan.