Efficient werken met GLClassifications voor rapportages over veel Exact Online administraties

Op het gebruik van GLClassifications krijgen we vanuit Exact Support opmerkingen over het grote aantal API calls dat gemaakt wordt voor ruim 400 administraties. Zie ook Itgeneor192/itgeneor229 Exact Online: no remaining capacity - 15 van mvk.

Van normale API naar GlClassificationsBulk

Het laaghangend fruit is om over te stappen van GLClassifications naar GLClassificationsBulk. De verwerkingstijd gaat dan van 242 seconden naar 27 seconden:

Kies 5 willekeurige administraties:

use 
select code
,      'eol' 
from   SYSTEMPARTITIONS@DataDictionary 
where  provider_name='ExactOnlineAll' 
order 
by     code 
limit  5

Oude code voor reproductie voor random 5 administraties:

select count(*)
from   ExactOnlineREST.Financial.GLClassifications@eol

Resultaat na 242 seconden:

COUNT
65.230
Nieuwe code:
select count(*)
from   ExactOnlineREST.Financial.GLClassificationsBulk@eol

Resultaat na 27 seconden:

COUNT
65.230

Het datavolume per administratie daalt daardoor echter niet. Het blijven 65.230 grootboekrekeningclassificaties verspreid over 5 administraties.

Overhead door RGS

Als ik de volgende query uitvoer, dan zie ik de aantallen per taxonomy:

select type
,      TaxonomyNamespaceDescription
,      count(*)
from   ExactOnlineREST.Financial.GLClassificationsBulk@eol
group
by     type
,      TaxonomyNamespaceDescription

met als uitkomst:

Type Omschrijving COUNT
Referentie GrootboekSchema versie 3.2 3.857
Referentie GrootboekSchema versie 3.0 3.009
Referentie GrootboekSchema versie 3.1 3.753
Referentie GrootboekSchema versie 1.1 2.351
Grootboekrekeningschema 94

Hierin zie je dat bijna alle regels betrekking hebben op RGS. Al die ruim 10.000 regels zijn echter in elke administratie hetzelfde.

Hoe kan ik met Data Replicator alleen de regels overhalen die betrekking hebben op het eigen grootboekrekeningschema?

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.