Er worden een aantal regels van GeneralLedgerDetailsV3 opgehaald, maar na een tijdje komt er een HTTP-error 524.
Message Code itgensop090
Exception The remote server returned an error: (524) .
Als ik “reset chache” doe en opnieuw probeer kan ik de error:
The name must be present.
Please add a name.
itgenboe341
krijgen. Deze error kan ik daarna niet meer weg krijgen.
Soms als ik niets opsla en PowerBI opnieuw opstart kan ik weer een error 524 krijgen, soms krijg ik direct de name-error. Over de name-error is al een Topic dus deze wil ik graag houden bij 524, maar het lukt dus niet altijd om te reproduceren, maar soms wel.
De HTTP 524-melding is een CloudFlare-specifieke melding. Blijkbaar gebruikt Twinfield CloudFlare als tussenlaag en treedt er een fout op in de communicatie tussen CloudFlare als proxy en Twinfield. Mogelijk komt dit door het volume aan data.
Als dit probleem ook optreedt bij gebruik van App Online met de recente release, dan wordt reeds gewerkt met een retry-mechanisme voor HTTP-status 524. Zonder verdere verbeteringen wordt dit probleem niet opgelost.
De oplossingsrichting is:
Verbetering van de Twinfield-specifieke delen van optimizer, door een between op jaar/periode met meerdere jaren om te schrijven naar losse API-calls. Op dit moment vindt partitionering uitsluitend per administratie plaats, wat voor accountancy-administraties voldoende is. Naar deze optimalisatie wordt momenteel gekeken inclusief het achterwege laten bij kleine administraties. Zodra hier meer over bekend is, zal dit bericht aangevuld worden.
Mogelijke workarounds zijn:
Geef een filter mee vanuit Power BI via een filterstap op bijvoorbeeld jaar >= 2022.
Rechtstreeks laden met Invantive SQL naar een SQL Server, Oracle of PostgreSQL-database. Gebruik hierbij bijvoorbeeld een for...loop in Invantive PSQL.
De eerste optie werkt goed indien het aantal transacties per jaar of periode te overzien is. De tweede optie werkt ook goed voor volumes boven de 100 miljoen rijen in een Twinfield-administratie.
Dank voor melden. Uit de logging blijkt dat op deze versie een zware logoperatie meeloopt om bovenste probleem beter boven water te krijgen. Deze logging qua data groeit echter boven de limiet van het geheugen van een tekstvariabele. De logging zal uitgeschakeld worden.
Het ophalen van de data is blijkbaar wel goed gegaan blijkens de logging.
De logging is uitgeschakeld via een release later op de dag. De foutmelding itgenboe344 en itgenboe361 zijn bekend als onderdeel van de nieuwe functionaliteit. Hier is op dit moment nog geen oplossing voor; zodra een release naar Bridge Online gaat na de frozen period zal hiervoor een oplossing ingebouwd zijn.
Ik moet ondertussen jaar >= 2021 invullen om geen Error 524 te krijgen. We gaan dit jaar meer boekingen doen dan in 2020 dus ik ben bang dat ik binnenkort >= 2022 moet doen of uberhaupt maar 1 jaar kan importeren.
Er was 13 dagen geleden gezegd dat er naar een andere partitionering gaat worden gekeken, is dit een onderwerp waar nog steeds naar wordt gekeken?
Ja, correct. Hier is naar gekeken en dit zal ook ingebouwd gaan worden. Het jaarwerk maakt echter dat dit nog even duurt. Voorlopige workaround is om twee of meer downloads te maken en die te mergen in Power BI: eentje voor 2020, eentje voor 2021, eentje voor 2022 en eentje voor 2023 bijvoorbeeld.
In release 23.0.76 is een view PeriodsWithTransactions opgenomen met de periodes waarop gefilterd kan worden zodat de kans op het optreden van een 524 HTTP-statuscode of itgentfr091 zo klein mogelijk is.
In principe zou met de volgende view per periode de data opgehaald kunnen worden, ware het niet dat de Invantive UniversalSQL-optimizer dit automatisch herschrijft naar een IN-clause in plaats van losse joins:
select glr.*
from PeriodsWithTransactions prd
join GeneralLedgerDetailsV3 glr
on glr.company_code = prd.company_code
and glr.fin_trs_head_yearperiod = prd.fin_trs_head_yearperiod
Er zal gepoogd worden een optimalisatie door te voeren op de verschillende financiele transactietabellen om PeriodsWithTransactions te gebruiken.
Een verbetering is opgenomen vanaf release 24.0.135 om ook relatief grote administraties qua aantallen transacties zonder aanpassingen betrouwbaar te verwerken in Power BI en/of SQL. Zie voor meer informatie:
