Tableau de bord/Chapter 3/1.6 — Créer et gérer les Domains
Chapter 3 · leçon 6 sur 12
CertaviaDomains.Database Configuration ou Classifications.Application Designer.Domains.ALN Domain — Permet de définir une liste de valeurs alphanumériques prédéfinies pour un attribut, assurant une saisie cohérente.NUMERIC Domain — Utilisé pour valider des entrées numériques, souvent avec des plages de valeurs ou des formats spécifiques.TABLE Domain — Permet de lier un attribut à une colonne d'une autre table de Maximo, offrant une validation dynamique et des listes de recherche basées sur des données existantes.SYNONYM Domain — Spécifique aux statuts, il permet de créer des libellés conviviaux (synonymes) pour des valeurs internes de statut (ex: "ATTENTE" pour WAPPR), sans modifier la logique métier sous-jacente.CROSSOVER Domain — Copie des valeurs d'un objet source vers un objet cible lors de la création ou de la modification d'un enregistrement, améliorant l'efficacité de la saisie.Database Configuration — Application essentielle pour associer un domaine à un attribut et reconfigurer la base de données après la création ou la modification d'un domaine.Application Designer — Peut être nécessaire pour ajuster l'interface utilisateur (UI) après l'ajout d'un domaine, par exemple pour ajouter un bouton de sélection de valeur.Les domaines sont une pierre angulaire de l'intégrité des données dans Maximo Manage. Ils agissent comme des règles de validation et des fournisseurs de listes de valeurs, garantissant que les informations saisies par les utilisateurs sont cohérentes, précises et conformes aux exigences métier. Cette architecture centralisée permet de gérer efficacement les données à travers l'ensemble du système.
Chaque type de domaine répond à un besoin spécifique, qu'il s'agisse de listes statiques, de plages numériques, de références à d'autres tables ou de la traduction de statuts internes en libellés compréhensibles. La gestion des domaines s'effectue principalement via l'application Domains, mais leur application et leur activation nécessitent souvent des étapes complémentaires dans Database Configuration et Application Designer.
Maximo propose plusieurs types de domaines, chacun conçu pour répondre à des besoins spécifiques en matière de validation et de présentation des données. Comprendre leurs différences est crucial pour choisir le type approprié lors de la configuration du système.
Le tableau ci-dessous compare les principaux types de domaines, leurs usages typiques et les applications Maximo clés impliquées dans leur configuration et leur utilisation.
| Type de Domaine | Description | Exemple d'Usage | Applications Clés |
|---|---|---|---|
ALN Domain | Liste de valeurs alphanumériques prédéfinies et statiques. | Liste de types d'équipement (ex: "Pompe", "Moteur", "Vanne"). | Domains, Database Configuration, Application Designer |
NUMERIC Domain | Définit des règles de validation pour des valeurs numériques (plages, formats). | Plage de températures acceptables pour un capteur (ex: 0-100°C). | Domains, Database Configuration |
TABLE Domain | Référence une colonne d'une autre table Maximo pour une liste dynamique. | Sélectionner un ASSETNUM parmi les actifs existants. | Domains, Database Configuration |
SYNONYM Domain | Permet de créer des libellés conviviaux pour des valeurs de statut internes. | Afficher "En Attente d'Approbation" pour le statut interne WAPPR d'un ordre de travail. | Domains, Database Configuration |
CROSSOVER Domain | Copie des valeurs d'un objet source vers un objet cible. | Copier l'adresse d'un fournisseur lors de la création d'une commande. | Domains, Database Configuration, Application Designer |
La configuration des domaines dans Maximo est un processus en plusieurs étapes qui commence dans l'application Domains et se poursuit souvent dans Database Configuration et Application Designer. Cette approche modulaire permet une grande flexibilité et un contrôle précis sur la manière dont les données sont gérées et présentées aux utilisateurs.
Une fois qu'un domaine est créé, il doit être associé à un attribut spécifique pour devenir actif. Cette association détermine quels champs utiliseront les règles de validation et les listes de valeurs définies par le domaine. La reconfiguration de la base de données est une étape critique pour appliquer ces changements au niveau du système.
Domains pour définir le type de domaine (ALN, NUMERIC, TABLE, SYNONYM, CROSSOVER) et ses valeurs ou règles. Pour un SYNONYM domain, on ajoute des synonymes aux valeurs internes existantes (ex: WAPPRMAN, WAPPRVP pour WAPPR).Database Configuration, associer le domaine créé à un attribut spécifique d'un objet métier (ex: associer un domaine ALN à l'attribut ASSETTYPE de l'objet ASSET). Si l'attribut est requis, un défaut pour le domaine est également requis.Database Configuration pour que les changements prennent effet. Il est important de noter que le système ne valide pas la valeur par défaut lors de cette étape, mais plutôt lors de l'insertion d'un enregistrement en application.ALN ou CROSSOVER, il peut être nécessaire d'utiliser Application Designer pour ajouter des éléments d'interface (ex: un bouton de sélection de valeur) ou de nouveaux champs si un CROSSOVER domain est impliqué.Le cycle de vie d'un domaine dans Maximo Manage illustre les étapes clés, de sa conception à son déploiement et sa maintenance. Il met en évidence les interactions entre les différentes applications et les actions requises pour garantir que le domaine fonctionne comme prévu et contribue à l'intégrité des données du système.
Ce processus souligne l'importance de la planification, de la configuration et des tests pour chaque domaine implémenté, afin d'éviter les erreurs et d'optimiser l'expérience utilisateur.
Un piège courant est de croire que Maximo valide les valeurs par défaut d'un domaine lors de la reconfiguration de la base de données. En réalité, le système ne vérifie pas la validité de la valeur par défaut à ce stade. L'erreur, si la valeur par défaut est incorrecte ou non conforme au domaine, n'apparaîtra que lorsque l'utilisateur tentera d'insérer un nouvel enregistrement dans l'application concernée. Par exemple, si un attribut est lié à un domaine qui n'accepte que "CREW4" et que la valeur par défaut est "CREW2", la reconfiguration se fera sans erreur, mais la création d'un enregistrement échouera.
Après avoir créé et associé un domaine à un attribut, il est facile d'oublier que des ajustements de l'interface utilisateur peuvent être nécessaires. Par exemple, pour un domaine ALN, un bouton de sélection de valeur (lookup) doit souvent être ajouté manuellement via Application Designer pour permettre aux utilisateurs de choisir parmi la liste des valeurs prédéfinies. Sans cette étape, l'utilisateur pourrait être contraint de saisir manuellement la valeur, ce qui annule une partie de l'avantage du domaine en termes de standardisation et de réduction des erreurs.
Il est important de savoir que si la plupart des domaines peuvent être supprimés lorsqu'ils ne sont plus utiles, les domaines SYNONYM sont spéciaux. Bien que vous puissiez ajouter des synonymes à une valeur interne existante (ex: "ATTENTE" pour WAPPR), vous ne pouvez pas ajouter de nouvelles valeurs internes aux domaines SYNONYM réservés par le système. De plus, la suppression d'un domaine peut avoir des conséquences sur les données existantes qui l'utilisent, nécessitant une analyse préalable pour éviter la perte d'intégrité des données.
Le rôle principal des domaines est de standardiser et de valider les données d'entrée, de réduire les erreurs et de fournir des listes de sélection aux utilisateurs. Ils sont configurés initialement via l'application Domains.
ALN domain et un TABLE domain ?
Un ALN domain définit une liste statique de valeurs alphanumériques prédéfinies. Un TABLE domain, en revanche, référence une colonne d'une autre table Maximo, offrant une liste de valeurs dynamique basée sur les données existantes dans cette table.
Database Configuration est-elle cruciale après la création ou la modification d'un domaine ?
Database Configuration est cruciale car c'est là que le domaine est associé à un attribut spécifique et que la base de données est reconfigurée pour appliquer ces changements au niveau du système. Sans cette étape, le domaine ne sera pas actif pour l'attribut désigné.
Le SYNONYM domain est utilisé pour afficher des libellés conviviaux pour les statuts internes (ex: "En Attente d'Approbation" pour WAPPR). Il est spécial car vous ne pouvez pas ajouter de nouvelles valeurs internes à ces domaines réservés par le système, seulement des synonymes aux valeurs existantes.
Bonne réponse : D
Pourquoi cette question existe — STU §3.6 — la question distingue la création d'un domaine (application Domains) de son association à un attribut précis (Database Configuration). Cette confusion fréquente fait croire que tout se passe dans Domains. En pratique, c'est dans la table window Attributes de Database Configuration que le lien final s'effectue.
Le contexte théorique d'abord — Un domaine est d'abord créé dans l'application Domains (ALN, Table, Numeric range, etc.), mais son association à un attribut spécifique d'un objet métier se fait dans Database Configuration, sur la table window Attributes, via le champ Domain.
Ce que Maximo en fait — version opérationnelle — Dans Database Configuration > sélectionner l'objet > onglet Attributes > sélectionner l'attribut cible > champ Domain = nom du domaine créé préalablement dans Domains, puis Configure Database pour appliquer.
Exemple chiffré — Un domaine ALN « PRIORITYCODE » à 4 valeurs (1 à 4) peut être lié à 3 attributs différents (WORKORDER.WOPRIORITY, TICKET.REPORTEDPRIORITY, PM.PMPRIORITY) en 3 opérations distinctes dans Database Configuration.
Analogie quotidienne — C'est comme créer une liste déroulante réutilisable (le domaine) puis devoir l'attacher manuellement à chaque champ de formulaire où elle doit apparaître (l'attribut, via Database Configuration).
Pourquoi A est faux — Pattern D6 mauvaise-app : Application Designer configure l'apparence visuelle des écrans, pas le lien attribut-domaine au niveau base de données.
Pourquoi B est faux — Pattern D4 demi-vérité : Domains crée et définit le domaine lui-même, mais ne réalise pas l'association finale à un attribut précis.
Pourquoi C est faux — Pattern D2 inventé : « Field Configuration » n'est pas le nom d'une application Maximo standard pour ce rôle.
Bonne réponse : A
Pourquoi cette question existe — STU §3.6 — la question vérifie quel type de domaine permet d'afficher dynamiquement un ensemble d'enregistrements issus d'un autre objet, ici l'objet ASSET. Les distracteurs proposent un type figé (ALN), un nom d'objet confondu avec un type de domaine (ASSET), et un type inexistant (DYNAMIC). En pratique, ce choix conditionne si la liste affichée reste statique ou se met à jour automatiquement.
Le contexte théorique d'abord — Un domaine TABLE est défini par un Object source (ex. ASSET), une List Where Clause filtrant dynamiquement les lignes retournées, et un Value field (ex. ASSETNUM). Contrairement à un domaine ALN qui ne contient que des valeurs fixes saisies manuellement, le Table domain interroge la table source à chaque utilisation.
Ce que Maximo en fait — version opérationnelle — Dans Domains > Add New TABLE Domain > Object = ASSET, List Where Clause = status = 'OPERATING' AND siteid = :siteid, Value = ASSETNUM ; ce domaine, une fois lié à un attribut via Database Configuration, affiche dynamiquement la liste des actifs correspondant au filtre pour le site courant.
Exemple chiffré — Un Table domain filtré sur 3812 actifs au total n'affiche que les 247 actifs en statut OPERATING du site courant, soit 6,5% de la base totale, recalculé à chaque ouverture du lookup.
Analogie quotidienne — C'est comme une liste de contacts filtrée automatiquement par « collègues du même bureau » plutôt qu'une liste figée tapée une fois pour toutes.
Pourquoi B est faux — Pattern D3 inverse : ALN ne gère que des listes fixes de valeurs saisies manuellement, l'exact opposé d'un affichage dynamique d'enregistrements liés.
Pourquoi C est faux — Pattern D9 quasi-synonyme : « ASSET » est le nom de l'objet source utilisé DANS un Table domain, pas le nom d'un type de domaine.
Pourquoi D est faux — Pattern D2 inventé : « DYNAMIC » n'est pas un type de domaine Maximo standard ; le comportement dynamique recherché est porté par le type TABLE.