Het lijkt er op dat de GLClassifications API wat beperkingen kent, doordat hij zowel administratie-specifieke gegevens bevat als systeembrede gegevens, en dat die systeembrede gegevens voor elke administratie weer opgelepeld worden.
Achterliggend ontwerpissue is dat de Exact Online API geen concept kent voor systeembrede API’s, net zoals er maar heel beperkt ondersteuning is voor API’s op abonnementsniveau.
Voordelen van Exact bulk API
Voor GLClassifications geldt dat de niet-bulk versie erg langzaam is als je alle gegevens ophaalt. Normaliter is een bulk-API pakweg 50% tot 100% sneller als je vijf administraties tegelijk opvraagt, maar hier is dat bijna 9x zo snel en dat zal qua serverload ook bij Exact meetbaar moeten zijn. De overstap naar GLClassificationsBulk is daarom zeker nuttig.
Echter, dit beperkt het datavolume niet. In de vervolgtekst zal ik ingaan op het beperken van het datavolume en uiteindelijk blijkt dat focus op het datavolume ook de snelheid nog significant verder zal verhogen.
Beperken datavolume
Volgens de documentatie zou je het GUID veld Type kunnen gebruiken om te filteren:
Division is optional. For taxonomies of Taxonomies.Type = 0 (general taxonomies), the Division is empty. For division specific taxonomies it is mandatory
maar zoals je zelf signaleert is Type altijd leeg. Dat is een code-bug of een documentatie-bug.
Je kunt dus niet sturen op de inhoud van Type om een onderscheid te maken tussen het systeembrede RGS-schema en de administratiespecifieke classificaties.
Echter, volgens de documentatie is er ook een kolom Division met een andere semantiek dan gangbaar. Deze waarde wordt door Exact Online alleen gevuld met de waarde van de divisie uit de URL als het gaat over een administratie-specifieke classificatie. De kolom Division geeft Exact Online tegenwoordig leeg terug als het gaat over een systeembrede classificatie zoals de verschillende RGS-classificaties.
Deze kolom is in de volgende BETA weer toegevoegd, maar dan met de naam SourceDivision omdat de waarde een andere betekenis heeft dan alle andere voorkomens van de kolom Division.
Op GLClassificationsBulk is een filter (where-clause) mogelijk op SourceDivision, maar dit filter kan niet doorgezet worden naar Exact Online API’s omdat het geen “server-side filterable” veld is: die is niet geimplementeerd door Exact.
Op de traditionele GLClassifications tabel kan hier ook op gefilterd worden, maar wordt het filter ook doorgestuurd. Dit duurt voor 1 Exact administratie circa 212 ms.
De metingen zijn ook uitgevoerd met 161 administraties:
use select code, 'eol' from systemdivisions@eol where status = 1
Het ophalen van de administratie-specifieke GLClassifications met:
select *
from GLClassifications@eol
where SourceDivision is not null
duurt 12 seconden voor 161 administraties.
Het ophalen via de bulk-API
select *
from GLClassificationsBulk@eol
duurt 412 seconden voor 161 administraties.
Het advies is dus om in dit specifieke geval de niet-bulk API te gebruiken, dus GLClassifications met het genoemde filter op SourceDivision:
select *
from GLClassifications@eol
where SourceDivision is not null
Aanpassing door Exact
Een bericht kwam binnen dat Exact de zorgen ter harte heeft genomen en dat er mogelijk een aanpassing beschikbaar gaat komen waarbij de RGS-classificaties (zoals voorheen) niet meer meekomen in GLClassifications.