Recharge complète de TransactionLinesIncremental

Questions (nl)
, ,
1

Récemment, j’ai commencé à utiliser ExactOnlineREST.Incremental.TransactionLinesIncremental@eol via Invantive Bridge Online (OData4) dans Excel/Power BI. Je m’attendais à ce qu’après le premier chargement complet, chaque rafraîchissement ne récupère et ne traite que le delta : les lignes modifiées et supprimées depuis la dernière fois. Ce que je vois dans les journaux ne correspond pas à cela. Je me demande si c’est un comportement normal ou s’il y a quelque chose qui ne va pas.

Environnement

  • Invantive Bridge Online 26.0.286
  • Une administration avec environ 170 000 lignes pour la table incrémentale
  • Cache disque HTTP 4 heures, cache de réponse Bridge 15 minutes

Ce que je vois dans IncrementalLoadEventLogEntries

  • Après le delta, il y a pratiquement à chaque rafraîchissement une réinitialisation basée sur le nombre de lignes : « Rechargement complet du cache incrémental … depuis que le nombre de lignes dans le cache actuel … dévie trop du nombre minimum de lignes autorisé calculé … ». Ensuite, « Reconstruction. Ne pas réutiliser les anciennes données. Rechargement complet … ».
  • Lors de chaque rafraîchissement, il est indiqué « Timestamp moved from to » avec des valeurs vides, et « No need to update incremental results since there was no previous version ».
  • Quelques fois : « Can’t find all data files for most recent download … Expecting 2 data files, found 0 ».

Ce que je vois dans les I/O de Session

  • Le delta lui-même semble bien fonctionner : sync/Financial/TransactionLines?$filter=Timestamp gt ...L avec seulement les lignes modifiées.
  • Cependant, après, suivent environ 170 pages de la table complète. Tant que le cache disque est valide, elles proviennent du cache, mais un rafraîchissement prend donc 60 à 80 secondes.
  • L’API Deleted est demandée à chaque rafraîchissement à partir de Timestamp gt 0L et gt 1L, chacun avec 4 pages. Je m’attendais à ce que cela démarre également à partir du dernier timestamp vu.
  • Les rafraîchissements successifs commencent avec la même valeur Timestamp gt ...L. Le timestamp ne semble donc pas avancer après un delta, ce qui fait que le delta devient de plus en plus grand.
  • Si le cache disque est expiré, après le delta, la table incrémentale complète est récupérée à nouveau sur Exact (environ 220 appels réels, plus de 3 à 8 minutes pour seulement cette table).

Ce qui me frappe
Avant le delta, la copie enregistrée correspond exactement à $count. Après le traitement d’environ 3 000 ID supprimés de l’API Deleted, il reste environ 3 000 lignes en moins. Il semble que les ID signalés comme supprimés existent encore dans Exact, et que cela provoque chaque fois une action de rechargement complète par le contrôle du nombre de lignes. Mais peut-être que j’interprète cela incorrectement.

Mes questions

  1. Est-il normal qu’après chaque delta la table complète soit reconstruite ?
  2. Est-il normal que l’API Deleted soit toujours lue depuis le timestamp 0 et que le dernier timestamp vu ne soit pas mis à jour ?
  3. Mon soupçon concernant les ID supprimés est-il correct, ou y a-t-il une autre explication pour le décompte de lignes différent ?
  4. Cela pourrait-il être lié à ce qui a été mentionné dans ce sujet concernant la version 26.0 sur les fichiers incrémentaux ?

Si ce n’est pas le comportement attendu : comment puis-je le résoudre pour que seul le delta soit traité ?

Je peux fournir des exportations du journal des événements et des I/O de Session sur demande.

2

Il est difficile de comprendre complètement le texte potentiellement généré par l’IA.

Le rechargement complet n’est en tout cas pas un comportement normal. Cela ne se produit que si l’algorithme estime que l’ensemble de données est incomplet.

Des milliers de lignes supprimées ne sont pas non plus courantes.

Le conseil est d’ajouter une capture d’écran d’une telle demande de rechargement comme décrit ci-dessous.

Informations complémentaires

Est-il possible d’ajouter une capture d’écran (anonymisée) des détails de la demande dans le Suivi en ligne sur Invantive Cloud comme décrit dans Meer inzicht met nieuwe Online Monitoring?

Vous trouverez les détails en cliquant sur la demande de téléchargement qui fait l’objet de ce sujet.

La demande de téléchargement contient généralement une instruction SQL dans laquelle le nom de la table est visible.

Veuillez laisser au moins les données suivantes visibles des deux colonnes :

  • la barre de titre avec l’ID de la demande,
  • le code d’état, la taille du réseau, le chemin et les heures dans la colonne de gauche,
  • le code d’erreur et le message d’erreur tout en bas de la colonne de gauche,
  • l’intégralité de la colonne de droite, y compris l’instruction SQL, le nom de la table et les valeurs des paramètres.

Par exemple :

image
image1474×640 49.6 KB

Vérifier le bon serveur et utilisateur

Vérifiez soigneusement que vous vous connectez au site Invantive Cloud avec le même nom d’utilisateur que celui que vous utilisez pour traiter des données via, par exemple, Invantive Bridge Online. Vous ne voyez que les demandes de l’utilisateur Invantive Cloud avec lequel vous vous connectez au site.

Vérifier la bonne demande et les détails

Assurez-vous de sélectionner d’abord la demande pour afficher les détails. Une seule demande doit être visible sur la capture d’écran.

Vérifiez également soigneusement si la demande a un chemin avec odata4, apps ou mcp. Les demandes avec d’autres chemins ne sont généralement pas pertinentes pour cet objectif.

Message d’erreur et conseils par e-mail

De plus, l’utilisateur Invantive Cloud qui a reçu le message d’erreur sur son adresse e-mail recevra généralement un e-mail avec un message d’erreur et des conseils en cas de message d’erreur dans Power BI, Power Query, Azure Data Factory, Qlik ou Tableau.

Le conseil est de vérifier les spams de l’utilisateur concerné à la recherche de tels e-mails envoyés depuis support@invantive.eu.

3

ID de demande : 0HNOTTS4MANND:00000003

Voici les captures d’écran :

image
image2911×1573 245 KB

Requête :

select ...
from   ExactOnlineREST.Incremental.TransactionLinesIncremental@eol
where  (Division = :w1 and ((([GLAccount = :w2 or [GLAccount] = :w3) or [GLOAccount] =:w4) or [GLAccount] = :w5))

Division : 3619926
Comptes de grand livre : quatre GUID différents
Résultat visible : 4119 lignes.
Traité : 175866 lignes nouvellement récupérées à partir de l’API Exact Online, 0 répondu à partir du cache, avec 181 appels API.
Durée : 230 secondes.
Partitions sélectionnées : 2

Version : Invantive Bridge Online 26.0.334.6277

4

Le rechargement de ce cache est causé par une mise à niveau de la version de protocole. L’ancien cache avait été créé conformément à la version de protocole 7 sous la version 26.0.286, tandis que les données étaient extraites de la version 26.0.334.

La journalisation interne, qui pourrait également apparaître dans les tables d’audit, enregistre ceci :

Found payload in unsupported HTTP disk cache format in file '/SOMEPATH/TransactionLinesIncremental/72070809c7b62ad341e7de06cb24e183.cache': protocol version 7 instead of 9, compressed True, encrypted True.

Cependant, ceci est un événement unique et ne devait pas se produire auparavant. L’analyse montre également qu’un bug apparaît dans la détermination du “timestamp”. Ce comportement n’est ni normal ni souhaité.

Un correctif sera appliqué dans la prochaine version 27.0, et si techniquement possible, sera aussi intégré dans la version 26.0.

5

Il y a une nouvelle version disponible qui devrait résoudre ce problème. Les modifications nécessaires sont disponibles à partir de la version 26.0.340 et dans toutes les futures versions BETA.

Cette nouvelle version est/sera mise en production sur Invantive Cloud.

Pour plus d’informations, voir :

6

Cette question a été automatiquement clôturée après 1 semaine d’inactivité. La dernière réponse donnée a été marquée comme solution.

Veuillez poser une nouvelle question via un sujet séparé si le problème se reproduit. Veuillez inclure dans la nouvelle question un lien vers ce sujet en collant son URL dans le texte.