Maximo peut appliquer la logique métier de nombreuses manières. Chaque approche présente certains avantages et différents niveaux de compétences techniques à mettre en œuvre. L'exigence d'un champ à l'écran peut être abordée de différentes manières.

La première approche pour créer des champs obligatoires dans Maximo consiste à définir un champ sur « obligatoire » via Application Designer ; il s'agit d'un moyen simple de rendre obligatoire un champ spécifique 100 % du temps dans une seule application. Il s'agit d'une excellente option pour les utilisateurs qui n'interagissent qu'avec une seule application dans Maximo et pour lesquels le champ est toujours obligatoire. La deuxième approche est utile lorsqu'un utilisateur souhaite ajouter une logique conditionnelle au champ « obligatoire » ; cela peut être fait en utilisant des restrictions de données. Ces restrictions relatives aux données peuvent être mises en œuvre au niveau d'un groupe de sécurité ou au niveau mondial. Je trouve que les restrictions globales en matière de données fonctionnent bien la plupart du temps. Cette approche est plus complexe que la modification apportée à Application Designer car vous devez écrire une clause where. C'est une solution incontournable dans mon sac à outils, car ils sont si polyvalents.

Les deux approches sont excellentes car elles peuvent afficher de manière visible un champ comme « obligatoire » dans l'application. Ces approches sont efficaces sur le plan de l'application tout en restant simples à mettre en œuvre et à prendre en charge. L'inconvénient est que lorsque le statut d'un bon de travail est modifié, un champ qui n'était pas obligatoire dans le statut précédent peut devenir obligatoire dans le statut récemment mis à jour. Par exemple, un ordre de travail au statut WAPPR passe au statut APPR, et un champ qui n'était pas obligatoire au statut WAPPR est obligatoire dans le statut APPR ; lorsque l'utilisateur change de statut, il reçoit une erreur générique indiquant qu'un champ est obligatoire. L'autre inconvénient est que la qualité de la logique conditionnelle dépend de la capacité de l'implémenteur à écrire une clause where.

Les scripts d'automatisation se distinguent par leur capacité à fournir une logique complexe accompagnée de messages clairs. L'ajout d'une logique métier personnalisée au changement de statut d'un enregistrement constitue un excellent cas d'utilisation pour les scripts d'automatisation. J'ai utilisé cette approche pour modifier l'état des actifs, les bons de travail, les demandes de service, les bons de commande et les éléments de configuration. J'ai découvert que les scripts d'automatisation me permettaient de délivrer des messages ciblés avec une logique qui peut être aussi complexe que nécessaire. Je vais partager quelques exemples courants.

Point de lancement

L'utilisation d'un point de lancement basé sur les attributs permettra à la logique de se déclencher chaque fois que le statut change. Dans l'exemple ci-dessous, j'implémente une validation de l'état de modification d'un actif. Si vous souhaitez exécuter la validation plus souvent, vous pouvez utiliser un point de lancement de sauvegarde des objets.

Message d'erreur

L'association du script d'automatisation à un message Maximo permet de transmettre des messages spécifiques et flexibles à l'utilisateur. Pour chaque script d'automatisation que j'implémente, j'aime avoir un message correspondant avec un paramètre auquel je peux transmettre un message. Ce message est configuré dans Configuration de la base de données de la boîte de dialogue Messages. Le « {0} » sera le paramètre que nous transmettrons avec un message personnalisé.

Une fois que vous avez un message dans le script d'automatisation, vous pouvez signaler une erreur en utilisant ce message. Notez que les deux premiers paramètres indiquent le message à utiliser. Le troisième paramètre est un tableau transmis au message. Lorsqu'il est appelé, le « {0} » du message remplacera la première chaîne du tableau. L'ajout d'un « {1} » à votre message correspondrait à la deuxième valeur du tableau.

service.error (« emx », « AssetStatusValidation », [« L'adresse est requise pour passer au statut ACTIF. »])

Exemples :

Adresse requise lorsque le statut est passé à ACTIF

si mbo.getString (« STATUS ») =="ACTIVE » et mbo.IsNull (« EMXAddress ») :

service.error (« emx », « AssetStatusValidation », [« L'adresse est requise pour passer au statut ACTIF. »])

Exiger une valeur pour toutes les spécifications d'actifs lorsque le statut passe à OPÉRATIONNEL

si mbo.getString (« STATUS ») =="OPERATING » :

MBOSetAssetSpec= MBO.getMboSet (« $EMXASSETSPECREQUIRED », « ASSETSPEC », « assetnum =:assetnum et siteid=:siteid »)

MBoAssetSpec = MBOSetAssetSpec.moveFirst ()

tandis que MBoassetSpec :

si MBOAssetSpec.isNull (« ALNVALUE ») et MBOAssetSpec.isNull (« NUMVALUE ») et MBOAssetSpec.isNull (« TABLEVALUE ») :

service.error (« emx », « AssetStatusValidation », ["Asset Spec" + MBoAssetSpec.getString (« ASSETATTRID ») + « ne doit pas être nul »])

MBoAssetSpec = MBOSetAssetSpec.moveNext ()

Toutes les tâches WO doivent être COMP pour passer à COMP

si (mbo.getString (« STATUS ») == « COMP ») :

MboSetTask = mbo.GetMboSet (« $EMXWOTASK », "WOACTIVITY », « historyflag=0 » et « istask=0 » et status ! ="COMP » et parent=:wonum et siteid=:siteid »)

if (pas MboSetTask.isEmpty ())

service.error (« emx », « WoStatusValidation », [« Ce bon de travail contient « +MBOsetTask .count () + « des ordres de travail enfants ouverts qui doivent être terminés pour terminer ce bon de travail. »])