Ik krijg sinds een paar dagen deze melding op de tabel InvoiceTerms:
Invalid JSON.
A comma character ‘,’ was expected in scope ‘Array’.
Every two elements in an array and properties of an object must be separated by commas.
Ik heb geen aanpassingen gedaan dus ik ben benieuwd waar deze fout vandaan komt?
En nog belangrijker: hoe krijg ik dit opgelost?
Een aanvulling: in een ander rapport krijg ik eveneens op de InvoiceTerms tabel de volgende (andere) foutmelding:
OData: Aanvraag mislukt:
De externe server heeft een fout geretourneerd:
(500) Interne serverfout.
Request timeout.
Please consider reducing the scope of your request or retry to send the message.
itgenoda055
De “Invalid JSON”-melding van Power BI is een generieke foutmelding. De daadwerkelijke foutmelding is te achterhalen via Invantive Bridge Online Monitoring. Meer informatie over de JSON-melding is te lezen in DataSource.Error: OData: Invalid JSON. A comma character ',' was expected in scope 'Array'. Every two elements in an array and properties of an object must be separated by commas.
Mocht u nog geen gebruik gemaakt hebben van de gratis uitlegsessie, dan raden we aan om deze in te plannen. Het analyseren van meldingen en beste keuzes voor Exact Online-tabellen komt dan ook aan bod.
De melding itgenoda055 hangt mogelijk samen met een vergelijkbaar probleem van een bug in de Exact Online API:
Welke foutmelding is te vinden in Invantive Bridge Online Monitoring bij het verzoek of in het scherm Systeemberichten van Invantive Cloud?
Dank voor dit antwoord, heb even gekeken en dit zijn volgens mij de meldingen:
Het vreemde is dat afgelopen maandag alles nog prima werkte en nu, zonder dat ik een enkele aanpassing heb gedaan, het nu niet meer werkt… Ik begrijp niet hoe dit kan?
Dank voor de aanvulling.
Het gaat dus om een itgenoda055 met onderliggende foutmelding:
Request timeout.
Please consider reducing the scope of your request or retry to send the message.
The remote server returned an error:
408 Request Time-out
Dit betekent dat Exact Online na maandag niet meer in staat is om binnen 30 seconden een antwoord te geven op een API-verzoek voor InvoiceTerms. Dit is sterk gelijkend op de performance-issues bij de GLAccountClassificationMappings.
Dit probleem is inmiddels toegevoegd aan Exact Online ticket 03539244. Als u hier meer spoed aan wilt toevoegen, dan kunt u overwegen een ticket in te dienen bij Exact Online Support en verwijzen naar genoemd nummer. Als het goed is, dan heeft u recent een e-mail gehad over een storing op Exact Online. Helaas zijn er in de maanden voor de zomervakantie vaak storingen op de Exact Online API’s.
De impact van deze storing op InvoiceTerms blijft op dit moment beperkt tot uw account en hangt mogelijk samen met de aantallen factuurtermijnen of andere instellingen. U kunt overwegen een filterstap toe te voegen om het aantal te verminderen, bijvoorbeeld termijnen voor de toekomst. Het is mogelijk dat Exact Online deze wel kan verwerken.
Duidelijk verhaal. Dank voor deze toelichting en voor het toevoegen van dit issue aan het ticket bij Exact.
Ik heb de tabel InvoiceTerms uit mijn rapporten gehaald en inderdaad; zonder deze tabel werkt het rapport weer prima.
Ik zal een ticket aanmaken bij Exact en verwijzen naar Exact Online ticket 03539244. Mocht dat iets bijdragen aan een versnelde oplossing, dan is dat mooi meegenomen.
Nogmaals dank voor deze toelichting!
Vraag aan Exact:
Ik kon de tabel Project.InvoiceTerms tot voor kort zonder enig probleem inladen. Nu opeens niet meer, en ik heb geen wijzigingen aan mijn rapportages aangebracht. Dus afgezien van filters of voorkeuren ben ik benieuwd hoe dit kan!?
Reactie van Exact op mijn ticket:
Er is aan onze kant wel een kleine wijziging aangebracht in dit endpoint. U bent de enige die select=* gebruikt en daardoor tegen deze foutmelding aanloopt. Kunt u wel velden selecteren en controleren of u dan zonder de foutmelding de gegevens op kunt vragen?
Enig idee wat ik nu kan doen om de tabel toch uit te kunnen lezen?
De 408 HTTP status in combinatie met time-out treedt incidenteel bij meerdere tabellen op sinds de zomer van 2021 (zie bijvoorbeeld Itgenoda055: HTTP 408 Request Timeout errors op Exact Online). We hebben hiervoor nog geen goede workaround.
De $select=* is een instelling die centraal door Invantive in de SQL-engine wordt ingesteld en voor alle Invantive SQL-gebruikers toegepast wordt. Dit geldt niet voor alle tabellen; het wordt per tabel handmatig bepaald en ingesteld. Het merendeel gebruikt $select=* in plaats van de (langere) versie met alle veldnamen.
Voor InvoiceTerms is dit vanaf release 22.0.219 omgezet naar expansie met alle veldnamen voor InvoiceTerms. Er is bij interne test geen achteruitgang gebleken, dus mogelijkerwijs dat dit de problemen vermindert. Deze release zal ergens de komende 7 dagen in productie genomen worden.
Merk op dat InvoiceTerms sinds 22.0.218 een aantal extra cruciale velden bevat zoals InvoiceId waardoor het nu mogelijk is om een cashflowprognose te maken, ook voor Exact Online projectmanagement.
Dank voor deze reactie, begrijp ik het goed dat het dus even wachten is op de in productie name van de nieuwe release? En dan geen garanties, maar het zou kunnen betekenen dat de tabel weer uitgelezen kan worden? Even geduld hebben dus?
Correct. Het is bij ons niet bekend waarom de 408 HTTP time-outs op Exact Online incidenteel optreden en zelfs bij herhaaldelijk opnieuw proberen zich niet herstellen.
Hoe kan ik te weten komen wanneer de nieuwe release in productie is genomen?
Het vervangen van select=* door een kolommenlijst is afgelopen weekend in productie genomen. Er is nog geen uniform overzicht wanneer een release in productie genomen wordt. Er is wel een overzicht van de wijzigingen op https://releasenotes.invantive.com.
Als ik nu de tabel probeer in te laden krijg ik nog dezelfde foutmelding, maar zie ook dat qua sql statement nog $select=* wordt gebruikt. Duurt het even voordat de nieuwe release actief wordt of moet ik iets veranderen in de wijze waarop ik de tabel probeer in te lezen oi.d.?
De select t.* is iets anders dan het OData3-verzoek aan Exact Online, alhoewel enigszins gelijkend.
Er treedt inderdaad nog steeds een itgenoda055 op met HTTP 408-melding (Timeout) vanuit Exact Online:
Request timeout.
Please consider reducing the scope of your request or retry to send the message.
The remote server returned an error: (408) Request Time-out.
Er is geen $select=* gebruikt zoals zichtbaar is in de URL:
Het lijkt nog steeds een omgevingsspecifiek Exact Online probleem te zijn zoals beschreven op Itgenoda055: HTTP 408 Request Timeout errors op Exact Online.
Advies is over enkele dagen nogmaals te proberen. Op Exact Online zijn er ook problemen met API-calls die incidenteel niet eindigen binnen 5 minuten. Een aantal verbeteringen zijn hiervoor doorgevoerd om het dan nogmaals te proberen. Mogelijkerwijs dat dit ook soelaas biedt voor dit probleem.
Helaas kunnen we in dit probleem voor Invantive SQL niks betekenen zolang de bug in Exact Online niet opgelost is. Andere producten zullen er waarschijnlijk ook last van hebben specifiek op deze omgeving.
Alternatief is om nogmaals met Exact Online contact op te nemen en te verwijzen naar het ticket 03539244. Echter, dit kan langere tijd duren. Het probleem is in januari 2022 gemeld.
Ik heb dit gemeld (toegevoegd aan mijn ticket) bij Exact, met als reactie dat dit wordt doorgegeven aan het technische team… Overigens vanochtend opnieuw geprobeerd de tabel uit te lezen, en er is wel iets veranderd, waar ik eerst vrij snel de foutmelding kreeg, duurde het nu een hele tijd alvorens ik een foutmelding kreeg. Zie de bijgevoegde screenshots…
Het zal nu inderdaad langer duren. Het gedrag voor het opnieuw proberen is verfijnd; voorheen werd vaak al na eerste poging gestaakt. Inmiddels is dat meestal 10x met telkens tenminste 23 seconden of langer.
Het onderliggende probleem blijft behouden. Dit is iets dat Exact Online zelf zal moeten oplossen.
Vanuit Exact Online Support is de vraag gekomen op ticket 03539244 voor specifiek welke call langer duurt inzake InvoiceTerms. Een eenduidiger verwijzing dan de GLAccountClassificationMappings is toegevoegd. Zodra Exact Online Support een update zullen zowel dit topic als Itgenoda055 Request timeout bij ophalen GLAccountClassificationMappings bijgewerkt worden.
Hopelijk blijft de zaak zo in beweging en komt er snel een oplossing…
Vandaag (29-06-2022) out of the blue weer eens geprobeerd de tabel InvoiceTerms in te laden in Power BI en guess what? Hij deed het weer!
Ik heb van Exact nog geen terugkoppeling op mijn ticket gehad, dus ik tast in het duister over wat er nu gebeurd is waardoor de tabel weer inleest, maar ik ben in ieder geval blij dat het weer werkt. (Hopelijk blijft dat ook zo!)
Reactie Exact:
Bedankt voor het stellen van onderstaande vraag aan Exact Support. Hierbij stuur ik je het antwoord.
Supportvraag: 03560420
Tabel InvoiceTerms kan niet worden uitgelezen
Oplossing:
Dank u voor de melding dat het is opgelost. Ik zie dat er aanpassingen zijn gedaan naar aanleiding van het technisch rapport. Het is dus niet een tijdelijk iets, de oplossing is blijvend.
Excuses voor het ongemak.
