Difficultés liées aux mises à jour des enregistrements et aux erreurs des utilisateurs

Un système Maximo mature comporte généralement des couches de configuration, de personnalisations, d'intégrations et de pièces mobiles. Souvent, plusieurs processus peuvent interagir avec un seul enregistrement. Récemment, j'ai travaillé dans un environnement où les ordres de travail étaient créés par une intégration ; une fois que le bon de travail était atteint, les nouvelles files d'attente de travail étaient créées, les planificateurs commençaient à mettre à jour l'enregistrement. Pendant les mises à jour, des intégrations sortantes ont été déclenchées, ce qui a conduit à une autre intégration entrante mettant à jour les enregistrements. Il y a également eu des escalades effectuant des mises à jour sur certains bons de travail. Tout cela pour dire que les utilisateurs et les tâches automatisées recevaient régulièrement des erreurs « BMXAA4200E - L'enregistrement a été mis à jour par un autre utilisateur », ce qui provoquait une certaine frustration pour les utilisateurs.

Corriger les erreurs « Enregistrement mis à jour par un autre utilisateur »

En ce qui concerne les erreurs « enregistrement mis à jour par un autre utilisateur », il existe autant de façons de les résoudre que de raisons pour lesquelles elles se produisent. Les articles liés ci-dessous décrivent deux approches qui peuvent s'avérer très utiles. Ces approches donnent une visibilité sur l'erreur au moment où elle se produit et ces approches devraient être à votre disposition.

https://www.sharptree.io/blog/2023/2023-07-25-updated-by-another-user/

https://www.linkedin.com/pulse/troubleshooting-mxrowupdateexception-error-ibm-maximo-cheremisenov

La puissance des scripts d'automatisation pour les pistes d'audit

Ce qui manque à la plupart des approches, c'est la capacité de suivre l'ensemble du cycle de vie d'un enregistrement. Traditionnellement, pour assurer le cycle de vie d'un enregistrement, des tables d'audit sont utilisées pour enregistrer chaque modification. La configuration des tables d'audit est utile, mais elle peut entraîner des frais supplémentaires importants et il peut être difficile de les supprimer une fois qu'elles ne sont plus nécessaires. Dans mon exemple de scénario, j'examinais des enregistrements spécifiques au cours des premiers jours suivant leur création. La conservation des données d'audit à long terme ne me préoccupait pas et je voulais quelque chose qui soit facilement activé et désactivé.

Grâce à un script d'automatisation, j'ai pu atteindre tous mes objectifs. J'ai pu l'ajouter au système sans interruption et le désactiver facilement une fois terminé. Depuis sa mise en œuvre, je suis retourné au script et je l'ai activé pour faciliter le dépannage à plusieurs reprises. Avec un point de lancement sur WORKORDER et WOACTIVITY save, j'ai pu enregistrer des informations de base à chaque fois qu'une sauvegarde était effectuée.

‍

# Configurer un enregistreur

depuis psdi.util.logging, importez MxLoggerFactory

ProjetechLogger=MxLoggerFactory.getLogger (« maximum »)

‍

# Extraire toutes les données que je souhaite enregistrer

MBOParent = MBO.getOwner ()

strParentName = « »

si MBOParent et MBOParent.getName () :

strParentName = MBOParent.getName ()

# Écrire une entrée de journal

ProjetechLogger.info (« Auto Script » + « ScriptName + ») a détecté une sauvegarde WO. Identifiant du site : "+MBO.getString (« SITEID ») + » WONUM : "+mbo.getString (« WONUM ») + » Modifier par : "+mbo.getString (« CHANGEBY ») + » This Mbo : "+mbo.getName () + » Parent MBO : "+strParentName+ » Interactif : » + str (interactif))

‍

Grâce à la journalisation supplémentaire, j'ai pu capturer les données dont j'avais besoin. En utilisant les données enregistrées en conjonction avec les identifiants de corrélation contenus dans le message du journal, j'ai pu rapidement obtenir une image complète du cycle de vie de création d'un bon de travail. À l'aide des données du journal, j'ai pu identifier certaines améliorations des processus qui ont éliminé une grande partie de la frustration des utilisateurs. Nous avons également pu identifier un ancien processus inutile.

Comment pouvez-vous l'utiliser ? Cette approche ne se limite pas aux bons de travail. Il peut être appliqué à tout scénario dans lequel un point de lancement de script d'automatisation peut être déclenché et où une journalisation supplémentaire est requise. Lorsque vous utilisez cette approche ou toute autre approche qui ajoute une journalisation supplémentaire, il est important de prendre en compte l'impact sur les performances. Chaque entrée de journal et chaque point de lancement de script d'automatisation utilisés ont un coût en termes de ressources et de performances.

Gardez votre environnement dynamique, activez la journalisation lors du dépannage et désactivez-la dès que possible.