Changements des GetConnectors dans Profit 15
Sur cette page, vous trouverez les changements importants et les points d'attention dans la fonctionnalité existante des GetConnectors (et AFAS Remote). Les changements pourraient affecter les liens existants avec AFAS Profit.
Qu'est-ce qui changera ?
Lors de la récupération des données via les webservices de Profit, les données ont été composées et traitées par l'application Profit elle-même. Les données ont ensuite été renvoyées aux webservices de Profit en format XML ou JSON. À partir de Profit 15, le traitement et la compilation du JSON et du XML ne sont plus effectués dans Profit mais directement dans la base de données SQL. Avec Profit 15 la récupération des données de Profit via nos GetConnectors sera donc beaucoup plus rapide ! Cette optimisation entraîne un certain nombre de changements.
Qu'est-ce qui fonctionne différemment ?
La génération de JSON ou de XML directement de la base de données SQL donne les différences suivantes :
- Les champs devises ont plus de chiffres après la virgule.
- Les champs numériques peuvent contenir des chiffres après la virgule, par exemple TVA 21,00.
- Pour les étiquettes qui contiennent une un point, vous recevez une notification dans Profit que cela n'est pas conforme aux définitions REST.
- SOAP option 3 (avec des éléments vides).
- Les champs de date et/ou d'heure peuvent être arrondis différemment.
- La sortie de Base64-output se présente sous un format légèrement différent.
- Le tri des tableaux pourrait varier si aucun tri n'est indiqué.
Champs devises
La sortie des champs de devises est différente. Cette sortie est actuellement conforme à la méta description. Un exemple de cette production ajustée est la valeur comptable des actifs fixes:
Dans les métadonnées, la valeur comptable est décrite comme suit :
Boekwaarde is als volgt in de metadata beschreven:
{
"id" : "Valeur comptable",
"fieldId" : "U005",
"dataType" : "décimal",
"Label" : "Valeur comptable",
"longueur" : 26,
"controlType" : 1,
"décimales" : 10,
"decimalsFieldId" : ""
},
Grâce à Profit 15, le champ est rendu avec plusieurs décimales.
Champs numériques
La sortie des champs numériques est différente. Cette sortie est maintenant conforme à la méta-description. Un exemple de cette production est le taux de TVA ci-dessous :
{
"id" : "Tarif",
"fieldId" : "U009",
"dataType" : "décimal",
"Label" : "Tarif",
"longueur" : 5,
"controlType" : 1,
"décimales" : 2,
"decimalsFieldId" : ""
},
Grâce à Profit 15, le champ est rendu avec plusieurs décimales.
Labels zonder punt via REST
Si un point d'une étiquette est utilisé dans Profit 15, l'utilisateur sera informé que cela n'est pas autorisé dans REST.
SOAP option 3 (avec des éléments vides)
Avec cette option, il est possible d'obtenir une balise vide dans le XML. Dans la situation antérieure, cependant, l'étiquette n'avait aucune valeur. Actuellement, une étiquette vide est alors renvoyée. Cette étiquette vide comprend maintenant aussi un espace nom.
Champs de date/heure
L'optimisation renvoie des données directement de la base de données SQL. Les champs de date/heure contiennent l'heure en SQL avec une subdivision en millisecondes. Dans Profit, les millisecondes ne sont pas utilisées. Pour compenser la différence maintenant, un arrondi est fait en ajoutant 0,498 millisecondes. C'est la raison pour laquelle il faut penser aux scénarios qui présentent un écart d’environ 2 millisecondes.
Si vous enregistrez vos champs de date/heure pour les utiliser comme filtre pour le prochain appel, la possibilité existe que vous recevrez des doubles lignes. La condition est que vous ayez récupéré et enregistré cette date/heure avec l'ancienne méthode (c'est-à-dire pendant Profit 14), et que vous l'ayez utilisée comme filtre avec la nouvelle méthode (dans Profit 15).
Récupérer des images dans Base64
Lors de la récupération d'images sur des pièces jointes, la sortie est base64-string. Le contenu de la nouvelle méthode ne sera pas différent de celui de l'ancienne, mais le formatage en base64 se différait légèrement. Le contenu sera désormais affiché sur une seule ligne.
Tri des tableaux
Nous recommandons toujours d'utiliser également un tri lorsque vous utilisez la fonction "Skip and Take". Si ce tri est absent, le SQL lui-même déterminera un tri (optimal). Cette méthode de tri pourrait être différente pour l'ancienne et la nouvelle méthode. Le conseil est donc de toujours donner un tri.
