Laden alle BTW-aangiftes Twinfield in SQL Server: itgenclr004 SSL connection could not be established

[trr]

Echter, ik probeer om via het volgende statement alle data van 2024 in te laden:

create or replace table tw_declarations@mss
as
select *
from Twinfield.Views.VatReturnsAsXbrl@tfd
where DECLARATION_YEAR = '2024'

Hierbij krijg ik vervolgens de volgende foutmelding.

An error occured - 2be638eb-cd57-45c5-8445-1d2bc4123917
itgenclr004: The SSL connection could not be established, see inner exception.
itgenclr004: Received an unexpected EOF or 0 bytes from the transport stream.

Ook bij dit statement (zonder filters) krijg ik foutmeldingen en kan ik de data niet laden naar Excel.

create or replace table tw_declarations@mss
as
select *
from   Twinfield.Views.VatReturnsAsXml@tfd

Kan ik ergens iets aanpassen nog?

[forums]

Deze foutmelding treedt waarschijnlijk op bij deze recursive SQL:

select *
from   Twinfield.Twinfield.VatReturnAsXbrlByDocumentId('285549', 19642, false)

op request ID “0HN2V1Q29KIJV:00000003”.

De foutmelding itgenclr004 met “The SSL connection could not be established” geeft aan dat de beveiligde verbinding naar Twinfield niet opgebouwd kon worden. De oorzaak is “Received an unexpected EOF or 0 bytes from the transport stream.”. De bijbehorende HResult is 0x80131620.

De onderliggende logging is itgensop091 met tekst:

Download failed on attempt #1 without further retries: itgenclr004: The SSL connection could not be established, see inner exception. itgenclr004: Received an unexpected EOF or 0 bytes from the transport stream.

De call stack is:

 at System.Net.Security.SslStream.ReceiveHandshakeFrameAsync[TIOAdapter](CancellationToken cancellationToken)
 at System.Net.Security.SslStream.ForceAuthenticationAsync[TIOAdapter](Boolean receiveFirst, Byte[] reAuthenticationData, CancellationToken cancellationToken)
 at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken) --- End of inner exception stack trace ---
 at System.Net.Http.ConnectHelper.EstablishSslConnectionAsync(SslClientAuthenticationOptions sslOptions, HttpRequestMessage request, Boolean async, Stream stream, CancellationToken cancellationToken)
 at System.Net.Http.HttpConnectionPool.ConnectAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
 at System.Net.Http.HttpConnectionPool.CreateHttp11ConnectionAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
 at System.Net.Http.HttpConnectionPool.AddHttp11ConnectionAsync(QueueItem queueItem)
 at System.Threading.Tasks.TaskCompletionSourceWithCancellation`1.WaitWithCancellation(CancellationToken cancellationToken)
 at System.Net.Http.HttpConnectionPool.SendWithVersionDetectionAndRetryAsync(HttpRequestMessage request, Boolean async, Boolean doRequestAuth, CancellationToken cancellationToken)
 at System.Net.Http.HttpMessageHandlerStage.Send(HttpRequestMessage request, CancellationToken cancellationToken)
 at System.Net.Http.DiagnosticsHandler.SendAsyncCore(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
 at System.Net.Http.HttpMessageHandlerStage.Send(HttpRequestMessage request, CancellationToken cancellationToken)
 at System.Net.Http.RedirectHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
 at System.Net.Http.DecompressionHandler.SendAsync(HttpRequestMessage request, Boolean async, CancellationToken cancellationToken)
 at System.Net.Http.HttpMessageInvoker.Send(HttpRequestMessage request, CancellationToken cancellationToken)
 at System.Net.Http.HttpClient.Send(HttpRequestMessage request, HttpCompletionOption completionOption, CancellationToken cancellationToken)
 at System.Net.HttpWebRequest.SendRequest(Boolean async)
 at System.Net.HttpWebRequest.GetResponse() --- End of inner exception stack trace ---
 at System.Net.HttpWebRequest.GetResponse()
 at Invantive.Data.Providers.Soap.SoapProvider.DoRequest(GlobalState owner, ExecutionOptions executionOptions, SqlExecutionStep sqlExecutionStep, HttpWebRequest request, String url, ObjectDefinition objectDefinition, String partitionCode, String callSafeNameOverrule, ParameterList parameters, Object requestData, String resultCacheId, String publicQueryParameters, ExecutionStatistics& executionStatistics)
 at Invantive.Data.Providers.Soap.SoapProvider.Post(GlobalState owner, ExecutionOptions executionOptions, SqlExecutionStep sqlExecutionStep, String relativeUrl, Dictionary`2 headers, Byte[] postData, ObjectDefinition objectDefinition, CacheSettings cacheSettings, String cachePostfix, ExecutionStatistics& executionStatistics, String acceptMimeType, String contentType, Boolean authenticate, Boolean preventRetry, String partitionCode, String method, String callSafeNameOverrule, ParameterList parameters, String publicQueryParameters, String additionalContextNativeCall, String dataContainerIdOverrule)
...

De WebException heeft status UnknownError en HttpRequestError is SecureConnectionError.

Dit betekent dat gedurende het opbouwen van de beveiligde verbinding met de Twinfield API-server het opzetten van de beveiligde verbinding faalde. De reden is onbekend.

Advies is de actie nogmaals te proberen.

Het mislukken van het opzetten gebeurt op een dusdanig laag niveau dat tot op heden dit nooit opnieuw geprobeerd werd. Er zal overwogen worden om eventueel een beperkt aantal hernieuwde pogingen te proberen om de impact van eventuele “glitches” in SSL-verwerkers te minimaliseren.

Merk op dat DECLARATION_YEAR een getal is; het is beter om '2024' te vervangen door 2024, maar dit heeft naar verwachting geen invloed op deze melding.

[trr]

Ik heb het nog een keer geprobeerd, maar nog steeds krijg ik een foutmelding. Dit blijft ook aan houden bij de XML variant als ik geen filters toepas.

[forums]

Een performance-issue is geidentificeerd:

Where clause van buiten view wordt niet in juiste volgorde toegepast

Bij het ophalen van Twinfield BTW-aangiftes via “Query 1”: -- -- Selecteer random 10 administraties. -- use select code, 'tfd' from offices@tfd limit 10 select /*+ http_disk_cache(false) http_memory_cache(false) */ count(*) from Twinfield.Views.VatReturnsAsXbrl@tfd where DECLARATION_YEAR = 2024 is de looptijd meerdere minuten. Echter, de volgende query (“Query 2”) met identiek resultaat is in minder dan 2 seconden klaar: select /*+ http_disk_cache(false) http_memory_cache(false) */ count…

Dit is echter niet de oorzaak van het probleem; het maakt hoogstens de kans van optreden groter.

[forums]

Om het performance-issue te omzeilen is getest in een grote Twinfield omgeving nadat een verbetering van herhaald proberen was doorgevoerd.

Per 5 administraties blijkt circa 1 seconde nodig om de BTW-aangiftes op te halen via:

set use-http-disk-cache@tfd false

set use-http-memory-cache@tfd false

use all@tfd

create or replace table tw_declarations@mss
as
select m.company_code
,      m.company_name
,      m.* except m.company_code, m.company_name prefix with 'DECLARATION_'
,      d.xbrl
from   Declarations@tfd m
join   VatReturnAsXbrlByDocumentId@tfd(m.company_code, m.Id) d
where  m.DocumentCode in ('VATICT', 'VATTURNOVER', 'YEARLYSUPPLETION')
and    m.Year = 2024

itgensop090 / HTTP-statuscode 524

Bij deze tests met honderden administraties trad 1x een HTTP-statuscode 524 op (itgensop090). Bij herhaling van de query echter niet meer.

De itgensop090 was:

error code: 524.
The remote server returned an error:
(524) .

voor documentId 24019, partitie 286017 op Twinfield.Twinfield.VatReturnAsXbrlByDocumentId, met call stack:

System.Net.WebException
Invantive.Basics.InvantiveSqlException
   at System.Net.HttpWebRequest.GetResponse()
   at Invantive.Data.Providers.Soap.SoapProvider.DoRequest(GlobalState owner, ExecutionOptions executionOptions, SqlExecutionStep sqlExecutionStep, HttpWebRequest request, String url, ObjectDefinition objectDefinition, String partitionCode, String callSafeNameOverrule, ParameterList parameters, Object requestData, String resultCacheId, String publicQueryParameters, ExecutionStatistics& executionStatistics)

De relevante meldingen zijn:

itgensop091: Download failed on attempt #1 without further retries:
itgensop068: POST try #1 from URL ‘https://api.accounting2.twinfield.com/webservices/declarations.asmx’.

Het optreden van een itgensop090 bij deze puntquery is vreemd. itgensop090 is tot op heden op Twinfield enkel gezien bij niet-gepagineerd ophalen van transacties uit grote Twinfield-administraties. Blijkbaar kan deze error ook optreden bij (sommige of specifieke?) heel kleine dataretrievals. Zie Where clause van buiten view wordt niet in juiste volgorde toegepast.

In een volgende release zal hiervoor een verbetering doorgevoerd worden.

Samenvatting

Het oorspronkelijke probleem met itgenclr004 lijkt niet meer op te treden na verbeteringen.

Advies is om in afwachting van een prestatieverbetering de uitgeschreven code van de view te gebruiken om SQL Server te vullen zoals hierboven getoond.

[trr]

Werkt dit nu ook voor de XML variant?

Als ik de query aanpas naar:

set use-http-disk-cache@tfd false

set use-http-memory-cache@tfd false

use all@tfd

create or replace table tw_declarations@mss
as
select m.company_code
,      m.company_name
,      m.* except m.company_code, m.company_name prefix with 'DECLARATION_'
from   Declarations@tfd m
join   Twinfield.Twinfield.VatReturnAsXmlByDocumentId@tfd(m.company_code, m.Id) d
where  m.DocumentCode in ('VATICT', 'VATTURNOVER', 'YEARLYSUPPLETION')
and    m.Year = 2024

dan krijg ik nu de volgende melding:

itgentfr248:
Het document type van dit Document word niet ondersteund door deze functie.

[forums]

Voor XML zal dit niet werken. De BTW-aangifte API’s van Twinfield zijn wat vreemd cq. we begrijpen de logica niet waarom XML en XBRL anders werken.

Voor XML is de viewinhoud:

select m.company_code
,      m.company_name
,      m.* except m.company_code, m.company_name prefix with 'DECLARATION_'
,      d.xml
from   Declarations m
join   VatReturnAsXmlByDocumentId(m.company_code, m.Id) d
where  m.DocumentCode = 'VATTURNOVER'

[forums]

Een verbetering is in productie genomen die eventueel optreden van itgensop090 bij ophalen BTW-aangifte zou moeten voorkomen.

[forums]

Deze vraag is automatisch gesloten na 1 week inactiviteit. 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.