AcumatiCares
Introduction
Notre produit, SPS Commerce EDI apporte des données EDI dans des tables de préparation dans Acumatica via Le service Web pour une importation ultérieure dans l’ERP. Plus précisément, les données JSON doivent être désérialisées, puis ajoutées aux objets de données Acumatica. Étant donné que nous contournons l’interface utilisateur lors du chargement de données dans le produit, il est possible de charger des données de chaîne dans le cache qui dépasseront les spécifications SQL lorsqu’elles seront insérées par l’ORM. Dans les itérations précédentes, le système Acumatica ORM tronquerait automatiquement ces données pour s’adapter au champ SQL. Il y a quelques années, cependant, l’ORM a été modifié de sorte qu’il tente d’insérer les données sans vérification et une erreur SQL est générée par la base de données si une spécification de champ est dépassée. J’avais besoin d’un moyen de rétablir ce contrôle et une éventuelle troncation. En outre, en raison de la taille de notre produit EDI, j’ai environ 20 flux de données entrants différents à vérifier avec d’autres à venir. Par conséquent, le défi consistait à valider les données de chaîne entrantes pour plusieurs DAC dans une base de code facile à gérer sans tailles de champ de codage en dur.
Solution
Check_Field_Lengths_InsertUpdate<T> is a generic method which means that the parameter data types are deferred until the method is called. After I’ve deserialized my JSON data and translated it into DAC objects, I call the method with the cache of the appropriate data view and the list of DAC objects as parameters. The method then loops through each DAC object accessing the DAC definition via the cache and checking each string field in the object for length. If necessary, the method truncates the incoming data and then inserts or updates the object (myCache.Update() does both!) via myCache.
GIST: https://gist.github.com/patrick711/9ff5b6e9da90bcc52e14803269be5dd7
Dans la version de production de cette méthode, un avertissement est généré pour l’utilisateur lorsqu’une troncation s’est produite. Puisqu’il s’agit de données intermédiaires, l’utilisateur a alors la possibilité de corriger les données et de les retraiter. De cette façon, notre flux de travail est protégé contre les erreurs fatales qui auraient pu faire tomber l’ensemble de la transaction.
Résumé
J’espère que vous avez trouvé cela intéressant et même si vous n’avez pas besoin de valider les données de chaîne, vous serez intéressé par la mise en œuvre de méthodes génériques pour traiter plusieurs types de DAC et garder votre code facile à maintenir.
Joyeux développement!
