Ce sera le premier d'une série d'articles de blog qui aideront à expliquer les scripts d'automatisation dans Maximo. Je vais expliquer ce que c'est et pourquoi il a été ajouté au produit dans cet article. Dans les prochains articles, je me concentrerai principalement sur la manière de les utiliser pour répondre à différents types d'exigences de personnalisation, mais j'aborderai également certaines fonctionnalités relativement inconnues qui existent dans les scripts d'automatisation, soulignerai les avantages et les inconvénients des options de personnalisation (y compris les options autres que les scripts d'automatisation) et discuterai de certaines de nos meilleures pratiques en matière de création de scripts. Avoir une certaine expérience du codage sera bénéfique, mais je vais essayer de vous aider à expliquer la majeure partie du code afin que vous puissiez comprendre pourquoi je fais ce que je fais. Et si vous avez des questions, n'hésitez pas à les poster sur le forum Maximo afin que d'autres puissent également bénéficier de la réponse.

Maximo est un produit hautement configurable (consultez notre Des solutions page pour nos offres). Avec un minimum de compétences techniques, les utilisateurs peuvent ajouter de nouveaux champs, modifier l'écran ou restreindre les valeurs des attributs dans Maximo. Mais une fois que vous commencez à avoir besoin d'aller au-delà de ces fonctionnalités, les gens commencent à se poser des questions sur les scripts d'automatisation et les personnalisations Java. Et si c'est quelque chose que vous n'avez jamais fait auparavant, cela peut être assez intimidant au début. J'espère que cette série de blogues vous aidera à éliminer la plupart des intimidations et vous permettra d'atteindre vos objectifs commerciaux plus rapidement.

Commençons par parler de ce que sont les scripts d'automatisation dans Maximo. Pour ceux qui ne le savent pas, les scripts d'automatisation sont du code personnalisé. Il peut s'agir de petits scripts (certains ne comportent qu'une seule ligne) ou de très gros scripts (certains contiennent presque un millier de lignes de code). Ces scripts sont généralement écrits en Python ou JavaScript car ce sont les deux langages pris en charge par défaut dans Maximo, mais n'importe quel langage JSR 223 peut être utilisé si vous le configurez. Des scripts d'automatisation ont été ajoutés dans Maximo 7.5 (un précurseur existait dans les versions informatiques de Maximo antérieures) et ont été considérablement améliorés dans Maximo 7.6. IBM a continué d'améliorer les scripts d'automatisation dans divers packs de fonctionnalités depuis la sortie de la version 7.6. Ainsi, les utilisateurs de la dernière version de Maximo 7.6 (actuellement 7.6.0.9) pourront utiliser certaines fonctionnalités qui n'existaient pas dans les versions précédentes. Lorsque cela se produira dans nos exemples, j'essaierai de préciser quelle version l'a prise en charge en premier et de mentionner des options alternatives si possible.

Les scripts d'automatisation sont généralement liés à un événement dans Maximo à l'aide d'un point de lancement. Certaines des fonctionnalités les plus récentes (comme les intégrations) n'ont pas de point de lancement défini et sont appelées à l'aide d'une structure de dénomination spéciale sur le script. Il est essentiel de comprendre ces options de point de lancement pour développer Maximo (nous aborderons tous les points de lancement en détail dans cette série de blogs). Cette flexibilité des options d'événements vous permet d'exécuter votre code au moment le plus approprié. Cela permet à votre script d'être appelé moins fréquemment, ce qui peut améliorer considérablement les performances dans Maximo pour les scripts les plus complexes.

Quand devez-vous utiliser les scripts d'automatisation ? Une fois que vous avez découvert la puissance des scripts d'automatisation, il est souvent tentant de les utiliser pour tous vos besoins de personnalisation. Je suis fermement convaincu que les scripts ne doivent être utilisés que lorsque le framework Maximo ne prend pas déjà en charge ce que vous devez faire. Un exemple courant que j'ai vu où les scripts d'automatisation sont mal utilisés est l'utilisation d'un script d'automatisation pour croiser une valeur d'un objet à un autre. S'il n'y a pas de transformation, il vaut mieux utiliser un domaine croisé. Ils se déclenchent de manière fiable (des événements peuvent être supprimés, empêchant ainsi le lancement de votre script, ou l'application peut être en mode administrateur, ce qui empêche le lancement de tous les scripts) et fonctionnent honnêtement.

Un autre exemple que je vois mal utilisé est l'utilisation d'un script d'automatisation pour exiger ou rendre les champs en lecture seule. Dans certains scénarios, cela est logique, mais dans la plupart des cas, l'utilisation d'une restriction globale des données permet d'y parvenir de manière bien meilleure et plus fiable. Comme précédemment, si votre script ne se déclenche pas (soit l'événement est supprimé, soit en mode administrateur), il se peut que quelque chose que vous essayez de restreindre/exiger d'un processus métier ne soit pas défini. Et en essayant de regrouper la plupart des exigences de terrain en un seul endroit, il est facile de savoir quand vous cherchez à identifier où cela est requis et dans quelles conditions.

Quels sont les avantages et les inconvénients des scripts d'automatisation par rapport à la personnalisation Java ? Le principal avantage d'Automation Scripting est le processus de déploiement. Contrairement à la personnalisation Java, les scripts d'automatisation peuvent être ajoutés, modifiés ou désactivés sans interruption. Rien que cela rend la situation difficile à battre pour la plupart des organisations. Le déploiement des personnalisations Java peut prendre des heures si vous êtes en cluster, ce qui allonge considérablement le développement et les tests, en plus de l'impact commercial lié à la perte de l'accès à Maximo. Certains développeurs me disent souvent que ce n'est pas un problème car l'entreprise a prévu des heures d'arrêt pour déployer ces modifications. Mais que se passe-t-il lorsque votre code présente un bogue ? Les problèmes sont souvent identifiés pendant les heures de bureau et les personnalisations Java ne peuvent pas être désactivées ou modifiées sans interruption.

Un autre avantage est que vous pouvez facilement lier votre script d'automatisation au déclenchement de plusieurs événements dans Maximo. Par exemple, si vous souhaitez qu'un script se déclenche lorsque les attributs assetnum ou location changent, vous pouvez le faire à l'aide d'un script d'automatisation et de deux points de lancement. Vous pouvez appeler le même morceau de code avec Java Customizations, mais vous devez étendre (ou écrire) la classe de champ pour chacun des attributs, ce qui nécessite de conserver plus de code que la simple écriture de cette partie commune.

L'un de mes avantages préférés est que l'utilisation des scripts d'automatisation vous permet de tirer parti des deux langues. Les scripts en général sont généralement plus simples que le même code en Java. Mais là où cela fait vraiment gagner du temps, c'est lorsqu'il existe un très bon moyen de faire quelque chose dans Jython qui est plus difficile ou plus détaillé en Java. Un exemple simple est de vérifier si un attribut est défini dans Maximo. Parfois, lorsque vous appelez GetString (« ATTRIBUTENAME »), vous obtenez une valeur NULL en retour, parfois vous obtenez une chaîne vide. En Java, vous devez écrire les deux vérifications comme getString (« ATTRIBUTENAME ») ! =null et getString (« ATTRIBUTENAME ») ! = « ». Dans Jython, je peux simplement dire si mbo.getString (« ATTRIBUTENAME ») et il gérera les deux scénarios. Ne vous inquiétez pas pour l'exemple (nous en parlerons dans notre prochain article de blog), j'ai simplement pensé qu'il était plus facile de le mettre en évidence.

L'utilisation de scripts d'automatisation pour la personnalisation présente certains inconvénients. La première est que si c'est quelque chose qui doit être fait en mode Admin, vous devrez écrire du code Java. Nous ne pensons pas que ce soit un cas d'utilisation courant car la plupart de nos personnalisations sont orientées vers les entreprises et les transactions commerciales ne devraient pas avoir lieu en mode administrateur pour des raisons autres que la simple création de scripts.

Un autre exemple où les personnalisations Java sont meilleures est lorsque vous devez remplacer une méthode pour supprimer la logique. Par exemple, supposons qu'IBM fasse quelque chose que vous ne voudriez pas voir se produire dans l'un de ses fichiers de classe. Vous pouvez essayer d'annuler ce qu'ils font dans cette méthode dans un script, mais si vous écrivez une classe Java, vous pouvez simplement empêcher l'exécution du code et simplement exécuter votre code personnalisé. Encore une fois, ce n'est pas courant pour nous, car si IBM fait quelque chose, il faut probablement le laisser tranquille, sinon vous risquez de provoquer d'autres problèmes par la suite.

Enfin, il arrive parfois qu'un script d'automatisation ne soit pas possible. IBM a continuellement ajouté des événements supplémentaires que les scripts d'automatisation peuvent écouter et a amélioré les fonctionnalités (comme les boîtes de dialogue Oui/Non/Annuler), mais vous devrez parfois faire quelque chose qui n'est tout simplement pas possible avec le framework actuel. Certaines seront améliorées dans les prochaines versions (comme la possibilité de fermer une boîte de dialogue !) , et certains n'y arriveront peut-être jamais. Les scripts d'automatisation n'auront jamais une couverture à 100 %, mais ils aideront l'administrateur moyen de Maximo à accomplir des choses incroyables.

‍