AcumatiCares
Introduction
Notre produit, SPS Commerce EDI apporte des données EDI dans des tables de préparation dans Acumatica via un 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. Comme nous contournons l'interface utilisateur lorsque nous chargeons des données dans le produit, il est possible de charger dans le cache des données sous forme de chaînes 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 ORM Acumatica tronquait automatiquement ces données pour les adapter au champ SQL. Cependant, il y a quelques années, l'ORM a été modifié de telle sorte qu'il tente d'insérer les données sans vérification et qu'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 troncature. De plus, en raison de la taille de notre produit EDI, j'ai environ 20 flux de données entrants différents à vérifier et d'autres sont à venir. Par conséquent, le défi consistait à valider les données de chaînes entrantes pour plusieurs CED dans une base de code facile à gérer sans coder en dur la taille des champs.
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 troncature s'est produite. Comme il s'agit de données provisoires, l'utilisateur a la possibilité de corriger les données et de les retraiter. De cette manière, notre flux de travail est protégé contre les erreurs fatales qui auraient pu interrompre toute la transaction.
Résumé
Nous espérons que vous avez trouvé cela intéressant et même si vous n'avez pas besoin de valider des données de type chaîne de caractères, vous serez intéressé par la mise en œuvre de méthodes génériques pour traiter plusieurs types de DAC et maintenir votre code facile à maintenir.
Bon développement !
