Pourquoi l’erreur BMXAA4211E bloque-t-elle la duplication ou la révision ?

Dans IBM Maximo et MAS Manage, les tables de détails — telles que les lignes de tâches d’intervention (WOACTIVITY), les qualifications requises (JOBLABOR / WPQUAL) ou les lignes de matériel — s’appuient sur des clés composites strictes pour garantir l’unicité de chaque enregistrement.

Lorsque l’utilisateur déclenche une action automatisée de copie (comme la duplication d’un Ordre de Travail ou la révision d’une Gamme Opératoire), le framework MBO instancie simultanément plusieurs lignes enfants en mémoire. Si l’incrémentation de l’identifiant séquentiel ou de la clé métier échoue à détecter un enregistrement déjà présent ou en cours de création, la base de données rejette l’instruction INSERT avec le message critique :

BMXAA4211E - Database error number -803 / ORA-00001 / 2601 has occurred. Unique constraint violation.

Mécanisme de conflit sur les clés composites

La collision survient généralement dans trois scénarios précis :

  1. Concurrence d’attributs clés : deux lignes d’une même gamme référencent la même qualification (QUALID) ou le même numéro de tâche (TASKID) au sein d’une révision.
  2. Désynchronisation des séquences : la séquence SQL en base (MAXSEQUENCE) est en retard par rapport à la valeur maximale réellement stockée dans la table cible (souvent après un import massif SQL ou MIF).
  3. Anomalie standard sur les qualifications (APAR DT496570) : lors de la révision d’un Job Plan contenant des qualifications liées à une équipe (AMCREW), le moteur tente de recopier deux fois la même contrainte de qualification.

Schéma 61A — Mécanisme de rejet lors de l’insertion d’un doublon MBO

flowchart LR A["Action : Réviser Gamme / Dupliquer OT"] --> B["Instanciation MboSet enfants"] B --> C{"Clé composite unique ?"} C -->|"Non (Conflit mémoire/base)"| D["Rejet SQL (-803 / ORA-00001)"] D --> E["Exception UI : BMXAA4211E"] C -->|"Oui"| F["Commit transactionnel validé"]
Schéma technique

Les tables système à inspecter

Composant Rôle dans le contrôle d’unicité
MAXSYSINDEXES Définit les index uniques déclarés dans le dictionnaire Maximo
MAXSYSKEYS Liste les colonnes composant chaque index unique
MAXSEQUENCE Stocke les compteurs et noms de séquences de chaque table
JOBLABOR / JPQUAL Tables fréquemment exposées lors des révisions de gammes

Exemple SQL de diagnostic en lecture seule

Avant toute intervention, il convient d’identifier l’index exact ayant levé l’exception dans les journaux SystemOut.log ou manage pod logs, puis de vérifier sa structure dans le dictionnaire Maximo :

-- Contrôler les colonnes formant l'index unique sur la table incriminée
SELECT i.name AS index_name, i.tbname, i.uniquerule, k.colname, k.colseq
FROM maxsysindexes i
JOIN maxsyskeys k ON i.name = k.ixname
WHERE i.tbname = 'JOBLABOR'
  AND i.uniquerule = 'U'
ORDER BY i.name, k.colseq;

Cette requête est strictement consultative. Elle permet de confronter les colonnes de contrainte aux données réellement saisies sur l’enregistrement source.

Procédure de résolution et contournement

  1. Identifier l’enregistrement source en anomalie : ouvrez la gamme opératoire ou l’ordre de travail d’origine et vérifiez s’il existe deux lignes partageant exactement la même combinaison d’attributs (même métier, même équipe et même qualification).
  2. Nettoyer le doublon fonctionnel : supprimez ou différenciez la ligne redondante avant de relancer l’action de révision ou de duplication.
  3. Resynchroniser la séquence (si l’index porte sur l’ID technique) : si le conflit porte sur l’identifiant unique interne (ex: JOBLABORID), vérifiez l’écart entre MAX(JOBLABORID) et la séquence en base, puis exécutez l’utilitaire de mise à jour des séquences ou ajustez la séquence SQL après arrêt des serveurs d’applications.
  4. Appliquer le correctif IBM : pour les environnements MAS Manage impactés par le bogue sur les qualifications d’équipes, déployez le Patch 9.2.4 (APAR DT496570).

Schéma 61B — Arbre de décision face à l’erreur BMXAA4211E

flowchart TD A["Erreur BMXAA4211E détectée"] --> B["Lire le nom de l'index dans les logs"] B --> C{"Index sur ID technique (*ID) ?"} C -->|"Oui"| D["Contrôler MAXSEQUENCE vs MAX(ID)"] D --> E["Resynchroniser la séquence SQL"] C -->|"Non (Clé métier)"| F["Inspecter les lignes enfants de l'enregistrement"] F --> G["Supprimer ou modifier le doublon métier"]
Schéma technique

Erreurs fréquentes lors du dépannage

Modifier l’index en base directement : supprimer un index unique via SQL (DROP INDEX) sans passer par Database Configuration désynchronise le dictionnaire Maximo et provoque des corruptions irréversibles lors des mises à jour futures. Ignorer les scripts d’automatisation : un script sur événement ADD ou DUPLICATE qui force une valeur par défaut identique sur toutes les lignes enfants générera systématiquement cette erreur.

Checklist de validation

  • L’index responsable de la violation a-t-il été formellement identifié dans les logs ?
  • Les lignes enfants de l’objet source respectent-elles la règle d’unicité métier ?
  • La duplication ou la révision s’exécute-t-elle désormais sans erreur SQL ?
  • L’action Configure Database (si utilisée) s’est-elle terminée sans avertissement ?

À retenir : l’erreur BMXAA4211E protège l’intégrité référentielle de Maximo ; il faut toujours corriger la donnée source ou la séquence plutôt que d’affaiblir la contrainte d’unicité.

Références