Introduction
Le dépannage des erreurs de plateforme sur Acumatica peut s'avérer difficile. En général, nous nous attendons à ce que les messages d'erreur nous indiquent exactement ce qui n'a pas fonctionné. Malheureusement, il y a des erreurs que les ingénieurs de la plateforme ne peuvent pas anticiper. Acumatica peut difficilement être blâmé lorsque mon logiciel personnalisé cause un problème lors de l'intégration avec le produit standard. Parfois, la plateforme xRP génère des erreurs génériques ou, pire encore, aucune erreur.
Par exemple, notre produit, SPS Commerce EDI , dispose d'un processus qui permet d'emballer automatiquement les expéditions sur la base d'un ensemble complexe d'options. Nous créons un nombre x de colis, le contenu de chaque colis contient un nombre y d'articles provenant des lignes d'expédition, nous attribuons des palettes, etc. Nous disposons également d'une page de traitement où le client peut emballer plusieurs envois à la fois. C'est comme mélanger des cartes ou faire un sandwich Dagwood géant. Le bouclage devient compliqué et j'ai rencontré quelques problèmes en cours de route.
Voici deux des problèmes les plus difficiles que j'ai rencontrés et je les détaille ici parce que j'espère que mon expérience sera utile à d'autres. Ces deux problèmes ne génèrent généralement pas d'exceptions et vous ne vous en apercevez que lorsque vous essayez de sauvegarder le travail à la fin du traitement.
Problèmes d'horodatage
Le redoutable processus Another a mis à jour l'enregistrement 'xxx'. Vos modifications seront perdues. L'erreur a de nombreuses causes possibles. L'une d'entre elles est que l'objet avec lequel vous travaillez actuellement a une valeur d'horodatage qui ne correspond pas à celle de la base de données et qui est plus jeune. Si vous essayez d'enregistrer le transport dans la base de données alors qu'il n'est plus à jour, le processus lèvera une exception. C'est évident, n'est-ce pas ? Cependant, il se peut que vous ayez mis à jour un objet CAD connexe qui, en raison d'une certaine connexion, entraînera également la mise à jour de l'objet d'en-tête sur lequel vous travaillez dans la base de données.
Par exemple, j'ai un code qui effectue des transactions sur plusieurs tables Acumatica dans un périmètre de transaction séparé. Je mets à jour SOPackageDetail et SOShipline avant de rafraîchir ces caches et de commencer à emballer. J'ai constaté que dans certains scénarios, une fois que la portée de la transaction est validée, l'objet SOShipline avec lequel je travaillais n'était plus à jour par rapport à la base de données. Lorsque j'ai voulu enregistrer mes modifications à la fin du traitement, l'exception a été levée. La conclusion est que d'autres processus peuvent mettre à jour le cache et même sauvegarder dans la base de données pendant que vous interagissez avec Acumatica. Si vous obtenez cette erreur, il se peut que vos objets aient besoin d'être rafraîchis à partir du cache.
Échec des insertions
L'un des problèmes les plus frustrants que j'ai rencontré en travaillant avec Acumatica est lorsqu'une insertion échoue sans exception. L'objet retourné à la fin d'une insertion de cache est nul et il n'y a pas d'erreur pour décrire le problème.
GIST: https://gist.github.com/patrick711/40653d1db0358bfcede94011fb7df22c
J'ai cru comprendre qu'il y avait trois raisons principales à cela :
- L'enregistrement inséré n'est pas du bon type. Ce que vous avez envoyé n'est pas du bon DAC. Celui-ci est assez facile à repérer
- La sauvegarde a été annulée dans un événement RowInserting. Il se peut qu'une logique d'événement liée à la mémoire cache annule l'insertion.
- Les attributs PXParent et PXLineNbr. Si votre CED se trouve dans une relation parent-enfant. Vous pouvez constater que l'enregistrement a été refusé parce que votre cache n'est pas synchronisé avec l'enregistrement .Current du CED principal. En particulier, l'attribut PXLineNbr peut poser des problèmes s'il ne peut pas calculer correctement le numéro de ligne suivant sur la base de l'enregistrement parent .Current.
Conclusion
Nous espérons que cet article vous donnera un point de départ la prochaine fois que vous rencontrerez des erreurs similaires. Il est facile d'avoir l'impression qu'il n'y a rien à faire dans ces cas-là. Au moins, la prochaine fois que vous vous taperez la tête contre votre bureau à cause d'erreurs vagues et non spécifiques, rappelez-vous que non, Acumatica ne vous déteste pas et que oui, il y a une raison à l'erreur, même si le message n'est pas suffisant.
Respirez profondément et examinez les relations que le DAC avec lequel vous travaillez peut avoir avec la base de données, le modèle d'événement et d'autres DAC.
Bon codage !
Patrick