Tableau de bord/Chapter 3/1.8 — Automation Scripts
Chapter 3 · leçon 8 sur 12
Les Automation Scripts représentent une pierre angulaire de la personnalisation de Maximo Manage, offrant une flexibilité considérable sans les contraintes du développement Java traditionnel. Ils s'insèrent directement dans l'architecture applicative de Maximo, permettant d'intercepter et de modifier le comportement du système à des points précis de son exécution.
Leur intégration est profonde : le code et la configuration des scripts sont stockés dans la base de données Maximo. Lors de l'exécution, les scripts compilés sont mis en cache, garantissant des performances optimales. Cette approche élimine le besoin de recompilation de fichiers ou de redémarrage du serveur d'applications, ce qui accélère considérablement le cycle de développement et de déploiement des personnalisations.
Certavia E[Automation Script]
E -- Langage --> F{Moteur Jython / JavaScript}
F -- Accède / Modifie --> G[Base de Données Maximo]
G -- Stocke --> H[Code Script & Configuration]
E -- Cache à l'exécution --> I[Scripts Compilés en Cache]
H -- Récupère --> E
E -- Résultat --> C
classDef primary fill:#1D9E75,stroke:#178A66,stroke-width:2px,color:#FFFFFF
classDef secondary fill:#F1F5F9,stroke:#475569,stroke-width:2px,color:#0F172A
classDef tertiary fill:#FFD700,stroke:#DAA520,stroke-width:2px,color:#0F172A
class A primary
class B secondary
class C primary
class D tertiary
class E primary
class F secondary
class G primary
class H secondary
class I tertiary
">
Historiquement, les personnalisations complexes dans Maximo nécessitaient des développements Java. L'introduction des Automation Scripts a offert une alternative puissante, réduisant la complexité et les coûts associés à la maintenance et aux mises à niveau. Cette section compare les deux approches.
Les Automation Scripts sont particulièrement avantageux pour les modifications de logique métier qui ne nécessitent pas de changements profonds dans l'architecture du système ou l'ajout de nouvelles fonctionnalités d'interface utilisateur complexes. Ils sont idéaux pour les validations, les calculs automatiques, et l'intégration légère.
| Caractéristique | Automation Scripts | Développement Java Personnalisé |
|---|---|---|
| Complexité de développement | Faible à modérée (Jython/JavaScript) | Élevée (Java, API Maximo, IDE) |
| Déploiement | Stocké en DB, pas de compilation/redémarrage serveur | Fichiers JAR, compilation, redémarrage serveur requis |
| Maintenance | Plus simple, modifications en direct via l'UI | Plus complexe, nécessite des compétences Java, gestion des versions |
| Impact sur les mises à niveau | Moins d'impact, souvent compatibles | Risque élevé de conflits, nécessite des tests approfondis |
| Performance | Bonne, scripts mis en cache à l'exécution | Très bonne, code compilé natif |
| Cas d'usage typiques | Validations de champs, calculs, règles métier simples, intégration MIF, actions de workflow/escalade | Nouvelles applications, modifications profondes de l'UI, intégrations complexes avec des systèmes externes |
| Compétences requises | Connaissance Jython/JavaScript, API Maximo | Connaissance Java approfondie, API Maximo, architecture J2EE |
| Coût total de possession | Généralement inférieur | Généralement supérieur |
La configuration des Automation Scripts dans Maximo se fait principalement via l'application `Automation Scripts`. Cette application permet de créer, éditer, activer et gérer les scripts. Chaque script est défini par un nom, une description, le langage de scripting (Jython ou JavaScript) et, surtout, un ou plusieurs points de lancement.
Les points de lancement (launch points) sont cruciaux car ils déterminent quand et où le script sera exécuté. Ils peuvent être associés à des objets métier, des attributs, des actions, des workflows, des escalades ou même des messages d'intégration. Par exemple, un script peut être configuré pour s'exécuter avant la sauvegarde d'un enregistrement `WORKORDER` pour valider certaines données, ou après la modification d'un `ASSETNUM` pour mettre à jour des informations connexes.
Un exemple concret pourrait être un script qui, lors de la création d'une nouvelle `WORKORDER` (Object Launch Point sur `WORKORDER`, événement "Add"), vérifie si le `ASSETNUM` est un équipement critique. Si c'est le cas, il pourrait automatiquement définir la priorité de la `WORKORDER` à "Urgent" et ajouter une description spécifique, sans aucune intervention manuelle de l'utilisateur.
Le cycle de vie d'un Automation Script dans Maximo est relativement simple et direct, reflétant sa nature de personnalisation légère. Il commence par la conception de la logique métier et se termine par son déploiement et sa maintenance. L'avantage majeur est la rapidité de mise en œuvre et la facilité d'ajustement.
Contrairement aux développements Java qui suivent un cycle de développement logiciel plus lourd (codage, compilation, déploiement WAR/EAR, redémarrage), les Automation Scripts sont gérés directement via l'interface utilisateur de Maximo, ce qui les rend très agiles pour les administrateurs et les consultants fonctionnels.
Les Automation Scripts peuvent être déclenchés par de nombreux événements. Un piège courant est de ne pas anticiper l'ordre d'exécution des scripts ou les effets secondaires qu'un script pourrait avoir sur d'autres processus métier ou scripts. Par exemple, un script `beforeMboData` qui modifie une valeur pourrait affecter la logique d'un autre script `afterMboData` ou d'une validation standard de Maximo. Il est crucial de bien comprendre le cycle de vie des objets et les points d'extension pour éviter des comportements inattendus ou des boucles infinies.
Bien que les Automation Scripts soient plus simples que le Java, le débogage peut être délicat. Les erreurs non gérées dans un script peuvent entraîner des blocages ou des messages d'erreur génériques pour l'utilisateur, sans indication claire de la cause. Sans une bonne gestion des exceptions (`try-except` en Jython, `try-catch` en JavaScript) et une journalisation adéquate (utilisation des fonctions de log de Maximo), identifier la source d'un problème peut être chronophage. Il est essentiel d'implémenter une journalisation robuste et de tester les scripts dans des environnements de développement avant le déploiement en production.
Bien que les Automation Scripts soient performants grâce à la mise en cache, un script trop complexe ou mal optimisé peut dégrader les performances du système. Par exemple, un script qui effectue des requêtes lourdes en base de données ou des boucles itératives sur de grands ensembles de données à chaque événement d'objet peut ralentir considérablement l'application. Il est important de garder les scripts concis, ciblés et d'optimiser les accès aux données. Pour des logiques très complexes ou des traitements de masse, d'autres mécanismes comme les `CRONTASK` ou les développements Java pourraient être plus appropriés.
Les Automation Scripts offrent une plus grande agilité, ne nécessitent pas de recompilation ou de redémarrage du serveur, sont stockés directement en base de données, et sont généralement plus faciles à maintenir et à mettre à niveau. Ils réduisent le coût total de possession pour de nombreuses personnalisations métier.
1. Object Launch Point : Exécuter un script avant la sauvegarde d'un `WORKORDER` pour valider des champs obligatoires. 2. Attribute Launch Point : Déclencher un script lorsque le `STATUS` d'un `ASSET` change pour mettre à jour un champ connexe. 3. Action Launch Point : Associer un script à un bouton personnalisé dans l'UI pour exécuter une logique métier spécifique.
À partir de Maximo 7.6, les langages de scripting nativement supportés pour les Automation Scripts sont Jython (une implémentation de Python) et JavaScript.
Le code et la configuration des Automation Scripts sont stockés directement dans la base de données Maximo. Cela signifie qu'aucune compilation externe n'est requise et que les scripts prennent effet immédiatement après activation, sans nécessiter de redémarrage du serveur d'applications.
Bonne réponse : D
Pourquoi cette question existe — STU §3.8 — la question vérifie la paire exacte de paramètres utilisée pour afficher un message d'avertissement stocké côté Database Configuration (table des messages), parmi plusieurs paires plausibles correspondant à d'autres niveaux de sévérité. En pratique, utiliser errorgroup/errorkey à la place de warngroup/warnkey change le comportement du script (blocage vs simple avertissement).
Le contexte théorique d'abord — Les messages affichés par Maximo (erreurs, avertissements, informations) sont stockés comme enregistrements dans la configuration des messages applicatifs, identifiés par un group et une key. Pour un avertissement, l'Automation Script référence ces deux identifiants via les variables warngroup et warnkey, qui pointent vers le message pré-enregistré à afficher.
Ce que Maximo en fait — version opérationnelle — Dans l'éditeur d'Automation Scripts, le script appelle l'équivalent de service.warning(warngroup, warnkey, params...), où warngroup/warnkey correspondent au message déjà défini (groupe + clé) dans la configuration des messages applicatifs.
Exemple chiffré — Un script déclenchant un avertissement sur 100% des work orders dont le coût estimé dépasse 5 000 $ référence un seul message pré-configuré via 1 paire warngroup/warnkey, réutilisable sur l'ensemble des launch points concernés.
Analogie quotidienne — C'est comme un panneau routier standardisé : le conducteur (le script) ne fabrique pas le panneau, il référence un panneau déjà homologué par son code (group/key) au bon endroit.
Pourquoi A est faux — Pattern D9 quasi-synonyme : errorgroup/errorkey affiche un message d'erreur bloquant, pas un simple avertissement.
Pourquoi B est faux — Pattern D2 inventé : « messagegroup »/« messagekey » n'est pas la paire de variables réelle utilisée par l'API d'Automation Script pour les avertissements.
Pourquoi C est faux — Pattern D9 quasi-synonyme : infogroup/infokey correspondrait à un message informatif, un niveau de sévérité différent de l'avertissement demandé.
Bonne réponse : C
Pourquoi cette question existe — STU §3.8 — la question identifie le rôle précis des Variables dans un Automation Script : faire le pont entre un attribut MBO et le code du script. Les distracteurs proposent des concepts d'infrastructure (pod), de configuration de déclenchement (Launch Points) ou de domaine, qui sont gérés ailleurs. En pratique, ignorer ce rôle empêche un script de réagir à la valeur réelle d'un champ.
Le contexte théorique d'abord — Une Variable d'Automation Script est liée (bind) à un attribut d'un Maximo Business Object (MBO). Sa fonction première est de récupérer la valeur de cet attribut au moment de l'exécution, permettant au script de lire (et parfois écrire) cette donnée sans accès direct bas niveau à l'objet.
Ce que Maximo en fait — version opérationnelle — Dans l'éditeur d'Automation Scripts, l'onglet Variables permet de créer une variable, de la lier à un attribut (ex. WORKORDER.STATUS), puis le script Python/Jython référence cette variable directement (ex. if status == 'APPR':) sans appel API explicite.
Exemple chiffré — Un script avec 3 variables liées (status, priority, estcost) évalue ces 3 valeurs en une seule exécution, contre 3 appels MBO distincts s'il fallait y accéder manuellement.
Analogie quotidienne — C'est comme une étiquette de prix scannée à la caisse : la variable « scanne » directement la valeur de l'attribut sans que le caissier (le script) ait à chercher manuellement dans le catalogue.
Pourquoi A est faux — Pattern D2 inventé : le pod d'exécution est une notion d'infrastructure OpenShift, sans rapport avec les Variables d'un script.
Pourquoi B est faux — Pattern D5 champ-frère : les types de Launch Points se configurent séparément (Object, Attribute, Action, Cron), pas via les Variables.
Pourquoi D est faux — Pattern D5 champ-frère : le lien à un Domain (synonym domain) est un cas particulier d'usage avancé des variables, pas leur fonction première.