Het initieel vullen van de incrementele cache voor TransactionLinesIncremental gebeurt regelmatig een time-out na 23 seconden (zoals kenbaar gemaakt via itgenoda315 of itgenoda316 foutmelding). Het ophalen van SyncTransactionLines werkt wel.
Dit probleem trad oorspronkelijk voornamelijk in Duitse administraties op, maar treedt inmiddels ook op in Nederland.
Een analyse is uitgevoerd.
Alternatief 1
Eerste poging was het verhogen van de time-out vna 23 seconden naar 97 seconden:
set http-get-timeout-ms@eol 97000
insert into exactonlinerest..NATIVEPLATFORMSCALARREQUESTS@eol
( url
, http_method
, content_type
)
values
( 'https://start.exactonline.nl/api/v1/123123/sync/Financial/TransactionLines?$orderby=Timestamp&$filter=Timestamp+gt+0L&$select=Account,AmountDC,AmountFC,AmountVATBaseFC,AmountVATFC,Asset,CostCenter,CostUnit,Created,Creator,Currency,CustomField,Date,Description,Division,Document,DueDate,EntryID,EntryNumber,ExchangeRate,ExtraDutyAmountFC,ExtraDutyPercentage,FinancialPeriod,FinancialYear,GLAccount,ID,InvoiceNumber,Item,JournalCode,LineNumber,LineType,Modified,Modifier,Notes,OffsetID,OrderNumber,PaymentDiscountAmount,PaymentReference,Project,Quantity,SerialNumber,Status,Subscription,Timestamp,TrackingNumber,Type,VATCode,VATPercentage,VATType,YourRef'
, 'GET'
, 'application/json'
)
De foutmelding verandert dan naar itgenoda055, welke optrad naar 30,500 ms:
itgenoda055
Request timeout.
Please consider reducing the scope of your request or retry to send the message.
The remote server returned an error: (408) Request Timeout.
De client-side time-out is dus vervangen door een server-side time-out. En nog steeds geen resultaten.
Vervolgens is de client-side timeout weer verlaagd naar 23 seconden en zekerheidshalve het aantal pogingen bij gebruik van TransactionLinesIncremental van 10 naar 2:
set http-get-timeout-ms@eol 23000
set download-error-web-timeout-max-tries@eol 2
Alternatief 2
Vervolgens is een poging gedaan om het veld YourRef weg te laten zoals in:
insert into exactonlinerest..NATIVEPLATFORMSCALARREQUESTS@eol
( url
, http_method
, CONTENT_TYPE
)
values
( 'https://start.exactonline.nl/api/v1/123123/sync/Financial/TransactionLines?$orderby=Timestamp&$filter=Timestamp+gt+0L&$select=Account,AmountDC,AmountFC,AmountVATBaseFC,AmountVATFC,Asset,CostCenter,CostUnit,Created,Creator,Currency,CustomField,Date,Description,Division,Document,DueDate,EntryID,EntryNumber,ExchangeRate,ExtraDutyAmountFC,ExtraDutyPercentage,FinancialPeriod,FinancialYear,GLAccount,ID,InvoiceNumber,Item,JournalCode,LineNumber,LineType,Modified,Modifier,Notes,OffsetID,OrderNumber,PaymentDiscountAmount,PaymentReference,Project,Quantity,SerialNumber,Status,Subscription,Timestamp,TrackingNumber,Type,VATCode,VATPercentage,VATType,YourRef'
, 'GET'
, 'application/json'
)
Dit geeft een resultaat van circa 1,4 miljoen tekens. Het toevoegen van YourRef geeft weer een itgenoda315.
Het laten staan van YourRef en het toevoegen van CostCenter geeft weer een juist resultaat van circa 1,4 miljoen tekens.
Schijnbaar maakt het niet uit welk veld weggelaten wordt, als er maar een veld weggelaten wordt.
De URL-lengte is niet exceptioneel met 651 tekens.
Poging 3
Vervolgens een poging om het initiele filter weg te laten:
$filter=Timestamp+gt+0L
Ook dan werkt de API-call weer zoals het hoort. Het weer terugzetten van het filter leidt weer tot een time-out met itgenoda315.
Poging 1
De data bevat als eerste waarde voor Timestamp 238894265.
Is dit de laagst voorkomende waarde? Het is in ieder geval meer dan 0.
Dit is gevalideerd met de volgende query:
select min(timestamp)
from SyncTransactionLines@eol
Het weglaten van het filter $filter=Timestamp+gt+0L bij de eerste stap is dus mogelijk.
Tweede Poging: wisselen naar alles
Een eerste poging om de volledige cache hiermee op te bouwen was succesvol. Echter, toen dezelfde test nogmaals werd uitgevoerd na 10 minuten, bleek de eerste URL goed te werken (zonder orderBy, filter), maar de tweede URL gaf weer dezelfde problemen, mogelijk vanwege $skipToken=240707534L.
Ook het gebruik van $filter zonder $skipToken leidde tot een time-out.
Het weglaten van zowel $filter als $skipToken leidde vlot tot resultaten binnen 1 seconde.
Het gebruik van $skipToken was ook zo snel als een willekeurig veld werd weggelaten zoals YourRef.
Vervolgens is het ophalen met skipToken geprobeerd met selectie van alle velden als in:
https://start.exactonline.nl/api/v1/123123/sync/financial/TransactionLines?$select=*&$skiptoken=240707534L
Hierdoor worden alle velden geselecteerd, maar de payload wordt dan vergroot van 1,4 miljoen tekens naar 2,2 miljoen tekens. Met andere woorden: voor Exact Online nemen de transportkosten toe met 50%.