Exact Online Incremental tabellen - verwijderde rijen

Voor het ophalen van data uit Exact Online willen wij gebruik maken van de Incremental-tabellen. Hiervoor maken wij gebruik van een Python-script om de Invantive Cloud aan te roepen (OData URLs). Vervolgens schrijven wij deze data weg naar Azure. Nu lijken echter de deleted rows bij niet meegegeven te worden bij het opvragen van deze incremental-tabellen. De werking van de incremental-tabellen is hieronder weergegeven:

De Incremental tabellen borduren voort op de Sync API’s van Exact Online. Ze gebruiken na eerste gebruik meestal 2 API calls bij Exact Online, onafhankelijk van het aantal rijen:

  • een aanroep naar de bijbehorende Sync Exact Online REST API om alle mutaties sinds de laatste keer op te halen, en
  • een aanroep naar de Deleted API van Exact Online om alle verwijderde rijen op te halen.

Deze informatie wordt dan gecombineerd met de uitkomsten van de vorige keer tot een nieuw resultaat. Vooral bij grote aantallen rijen is dit significant sneller en eenvoudiger dan het rechtstreekse gebruik van de Sync API’s.

Wat we nu doen is dat we de data van elke tabel vanuit Azure ophalen. Hieruit extraheren we vervolgens de laatste timestamp zodat we bij de incremental tabel alles op kunnen halen na deze timestamp. Vervolgens overschrijven voegen we de nieuwe regels toe en updaten we de regels waarin veranderingen hebben plaatsgevonden. Nu lijkt het er alleen op dat de deleted regels niet mee komen. Hoe worden deze deleted records meegegeven in de response van de incremental-tabellen?

Daarnaast leidt het gebruik van de incremental tabellen soms tot een enorme hoeveelheid calls met als gevolg een itgeneor229-error als gevolg. Wat kunnen we hieraan doen?

Het is by design niet mogelijk om de verwijderde rijen op te vragen via de *Incremental-tabellen. Dit zou eventueel kunnen door een query op SyncDeleted, maar er zijn talrijke pitfalls die niet door Exact zijn gedocumenteerd.

De *Incremental-tabellen bevat een volledige weerspiegeling van de actuele situatie na bijwerking door nieuwe rijen toe te voegen, oude te verwijderen en gewijzigde bij te werken.

Het bijwerken vanuit Python kan, maar is redelijk complex om goed, vlot en correct te bouwen. In Invantive Cloud kan het bijwerken van een Azure database met maar één SQL-statement in korte tijd gerealiseerd worden. Dit SQL-statement kan in een applicatiemodule gezet worden. Zie bijvoorbeeld Synchroniseer uw gegevens met één SQL-statement over meerdere cloudplatformen heen en Wat is Invantive App Online?.

Als een niet-incrementele lading van de Azure SQL Server database gewenst is, gebruik dan create or replace table of bulk insert (beiden gebruik inwending bulk insert voor maximale snelheid). Ook met grote aantallen rijen zal de Invantive SQL-engine de data streaming verwerken. Enige aandachtspunt is het beperken van de hoeveelheid netwerkverkeer; na compressie talrijke gigabytes is ongewenst.

De eerder aangehaalde tekst is verfijnd om duidelijker te maken dat het gaat om interne afhandeling:

De Incremental tabellen borduren voort op de Sync API’s van Exact Online en verbergen alle complexiteit en talrijke pitfalls bij het gebruik van de sync API’s intern. Ze gebruiken onderwater na eerste gebruik meestal 2 API calls bij Exact Online, onafhankelijk van het aantal rijen:

  • een aanroep naar de bijbehorende Sync Exact Online REST API om alle mutaties sinds de laatste keer op te halen, en
  • een aanroep naar de Deleted API van Exact Online om alle verwijderde rijen op te halen.

Het gebruik van *Incremental-tabellen kan niet leiden tot terugkerende itgeneor229 meldingen. Zelfs bij administraties met tientallen miljoenen rijen zal de dataset initieel geladen zijn na enkele dagen. Het uitlezen van een *Incremental-tabel kan wel leiden tot het tonen van de itgeneor229 melding, maar de oorzaak daarvan zit in de daaraan voorafgaande API-calls.

Via het Invantive Cloud scherm Sessie I/O’s is vlot de oorzaak te achterhalen. Meer tips over het beperken van het API-gebruik op Exact Online zijn te lezen op:

Mocht hiermee niet opgelost zijn, dan is advies om een apart topic hiervoor te maken en de problematiek duidelijker uiteen te zetten.

Deze vraag is automatisch gesloten na tenminste 2 weken inactiviteit nadat een mogelijk passend antwoord is gegeven. 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.