Bij het inladen van de database krijg ik de volgende melding:
2021-01-04 05:05:35.965 Error itgencun016: Error itgenoda061: itgenoda061: Request timeout. Please consider reducing the scope of your request. The remote server returned an error: (400) Bad Request.
Ook is het vreemd dat ik voor één administratie (de grootste) de transactieregels niet op kan halen. Heeft bovenstaande melding hiermee te maken?
Welke versie van Invantive betreft het?
Wat kun je hierover terugvinden in de logging zoals beschreven in Ondersteuning bieden bij Data Hub en andere on-premises producten?
Versie: 20.0.133
Logging geplaats in ticket SUP-15866
Hoi Daniel,
Ik krijg zelfde melding bij een dataload. Heb je hiervoor al een oorzaak/oplossing gevonden?
Dank alvast!
Kun je de call stack e.d. uit Systeemberichten hier toevoegen, inclusief de URL van het systeembericht?
Oplossing nog niet gevonden.
Loopt op andere licentie dus kan geen systeembericht vinden.
Is hier een oplossing voor?
De instructies om zelf systeemberichten te verzamelen kun je vinden in:
Je kunt ook de relatie met de BYOL (Bring Your Own License) vragen om aan te melden op Invantive Cloud en in systeemberichten te kijken.
Ik kan hier geen .log bestanden toevoegen. Kan ik deze in het ticket zetten?
He handigste is om de tekst uit de logging rondom
hier toe te voegen (met beleid), dus:
En ingepakt tussen drie backtics.
Snap niet wat je bedoelt, maar hierbij een stuk uit de tracefile:
05:13:00.11212-0-4: 05:12:58.37383-WPF-Run-c9564224-0623-41ac-9782-06324d13d28a-1: *** Process exception 'itgenoda061', show to user is True. ***
05:13:00.11212-0-4: 05:12:58.37383-WPF-Run-c9564224-0623-41ac-9782-06324d13d28a-1: System.Net.WebException
ValidationException
at System.Net.HttpWebRequest.GetResponse()
at Invantive.Data.Providers.OData.ODataProvider.DoRequest(GlobalState owner, ExecutionOptions executionOptions, HttpWebRequest request, String url, ObjectDefinition objectDefinition, String partitionCode, String callSafeNameOverrule, String anonymizedPostText, Boolean allowRetryOnConnectionLoss, ExecutionStatistics& statistics, ODataErrorProcessingInstructions& oDataErrorProcessingInstructions)
05:13:00.11212-0-4: 05:12:58.37383-missing-1: Reduced maximum number of usable partitions from 100,000 to 10,000 due to license constraints of license contract code 'L214350266' with ID 132305545358189680.
05:13:00.11212-0-4: 05:12:58.37383-missing-1: Reduced maximum number of usable partitions from 100,000 to 10,000 due to license constraints of license contract code 'L214350266' with ID 132305545358189680.
05:13:00.11212-0-4: 05:12:58.37383-WPF-Run-c9564224-0623-41ac-9782-06324d13d28a-1: itgenoda061: Request timeout. Please consider reducing the scope of your request.
The remote server returned an error: (400) Bad Request.
05:13:00.11212-0-4: 05:12:58.38947-WPF-Run-c9564224-0623-41ac-9782-06324d13d28a-1: Send message 'itgenoda061' of level 'Error' across Invantive Producer provider.
De drie backtics heb ik in je reactie toegevoegd; die zorgen in Discourse (het forumplatform gebruikt) dat het als code er in komt, zoiets als {code} op JIRA. Als je achter de drie backtics ook bijvoorbeeld “sql” zet, dan maakt hij het op voor SQL keywords.
De logging is niet helemaal volledig, maar te zien is dat Exact een melding teruggeeft:
Request timeout. Please consider reducing the scope of your request.
Dit zou ook in de foutmelding moeten terugkomen op het scherm. Exact krijgt het API verzoek dus niet afgewerkt binnen de daarvoor door hun gehanteerde responsetijden. Die tijden zijn ons niet bekend.
Ik kan vanwege het automatisch wegpoetsen van URL’s door Invantive SQL en andere vertrouwelijke dingen niet zien welke URL het betreft.
Dat kun je zichtbaar maken door direct na de code die de foutmelding veroorzaakt toe te voegen:
select *
from sessionios@datadictionary
local export results as "PAD\FILE.xlsx" format xlsx
Met sessionios@DataDictionary zoek je de uitgevoerde native requests terug. In geval van Exact Online zijn dat API requests.
In het Excelsheet zoek je dan de URL terug die naar de API server van Exact Online gestuurd is en een foutcode teruggaf (boolean veld SUCCESSFUL).
Vraag terzijde: betreft dit een bijzonder grote Exact Online omgeving?
Vraag 2 terzijde: is dit met datareplicatie met trickle loading, gewone datareplicatie of een los SQL statement?
Vraag 3: welk Invantive statement voer je uit om dit op te wekken?
Dank voor de snelle reactie.
Antwoord op vraag 1: Het hele probleem focust zich op het feit dat er een administratie is van de gebruiker waarbij we de Transactionlines niet op kunnen halen (vermoedelijk door de hoeveelheid data). Dit is dus een grote Exact omgeving.
Antwoord op vraag 2: Dit betreft datareplicatie met trickle loading
Antwoord op vraag 3: Het ‘gewone’ statement voor het inladen van de complete database, gebaseerd op xxdru en xxhosting.
Dank.
Kun je aangeven hoeveel grootboektransactieregels er in deze administratie zitten? Hoeft niet heel exact, ±10% nauwkeurigheid.
Kun je het statement hier specifiek toevoegen? Niet een procedure-aanroep, maar iets van select ... of een alter persistent cache.
Tussen de 4 en 5 miljoen regels, verspreid over 3 jaren (2018, 2019 en 2020).
select *
from ExactOnlineREST.FinancialTransaction.TransactionlinesBulk@eol
OK. We kunnen niks terugvinden van deze error voor dit statement.
We zien wel veel foutmeldingen de afgelopen weken op Cashflow/Payments en Cashflow/Receivables bij relatief grote Exact gebruikers (zowel bulk als traditionele API’s). Verder is er 2e Kerstnacht rond middernacht UTC een dergelijke error geweest op TransactionLinesBulk, maar dat was bij een andere gebruiker.
Advies is om het reproduceerbaar te maken en dan de native call log op te sturen naar Exact. Het is uiteindelijk een storing bij Exact op de API servers die de gevraagde capaciteit niet kunnen leveren soms blijkbaar.