En tant que professionnels de Maximo , nous partons souvent d'une hypothèse simple : le dossier ayant l'identifiant le plus élevé doit être le plus récemment créé. Dans un environnement traditionnel à serveur unique, cette hypothèse peut sembler se vérifier la plupart du temps.  
‍

Cependant, dans IBM Maximo Application Suite (MAS) Manage, surtout lors de l'exécution de plusieurs pods, cette logique peut mener à des conclusions erronées.
‍

Comprendre comment Maximo gère les séquences de base de données, met en cache les valeurs et attribue les identifiants sur plusieurs pods est essentiel pour les architectes, les développeurs, les rédacteurs de rapports et les équipes d'intégration.

Comprendre la gestion des séquences dans Maximo

Maximo s'appuie sur des séquences de base de données pour générer des identifiants uniques pour des dossiers tels que :

• Les ordres de travail

• Les demandes de service

• Les transactions d'inventaire

• Les transactions d'achat

• Les objets métier personnalisés
  ‍

La mise en œuvre varie légèrement selon la plateforme de base de données.

Oracle et Db2

Oracle et Db2 utilisent des objets de séquence de base de données natifs. La base de données elle-même gère la séquence et garantit l'unicité sur toutes les instances de l'application.
‍

Lorsque Maximo a besoin d'un nouvel identifiant, il demande la valeur suivante directement à la séquence de la base de données.

SQL Server

Historiquement, Maximo sur SQL Server utilisait la table MAXSEQUENCE plutôt que les objets de séquence natifs de SQL Server.
‍

Dans les versions plus récentes de MAS Manage, SQL Server peut tirer parti des séquences natives via le mécanisme NEXT VALUE FOR lorsqu'il est configuré de manière appropriée.
‍

Quelle que soit la plateforme de base de données, l'objectif principal reste le même :

Générer des valeurs uniques de manière efficace et sécurisée dans un environnement à forte concurrence.

Plusieurs pods MAS Manage partagent-ils la même séquence ?

La réponse courte est oui.
‍

Dans MAS Manage, tous les pods se connectent à la même base de données partagée. Par conséquent, ils partagent également les mêmes objets de séquence sous-jacents.
‍

Une séquence n'existe pas de manière indépendante au sein de chaque pod. Au lieu de cela :

• La séquence réside dans la base de données.

• Chaque pod demande des valeurs à la même séquence.

• La base de données garantit l'unicité.

• Plusieurs pods peuvent générer des enregistrements simultanément sans collision.
  ‍

Cela signifie que les pods d'interface utilisateur, d'intégration, Cron et de reporting consomment tous des valeurs provenant de la même source de séquence sous-jacente.

Qu'est-ce que le cache ? (Vous avez saisi le jeu de mots ?)

Pour améliorer les performances, Maximo ne demande généralement pas une nouvelle valeur de séquence à la base de données à chaque création d'enregistrement.
‍

Au lieu de cela, il réserve des blocs de valeurs et les stocke en mémoire.
‍

Par exemple :

• Le pod d'interface utilisateur 1 réserve les séquences 1 à 5

• Le pod d'interface utilisateur 2 réserve les séquences 6 à 10
  ‍

Ces deux plages sont uniques car elles ont été allouées à partir de la même séquence de base de données.
‍

Chaque pod dispose désormais de son propre cache local, ce qui permet de créer des enregistrements sans allers-retours constants avec la base de données.
‍

Cela améliore considérablement l'évolutivité et les performances du système. Cependant, c'est là que commencent de nombreux problèmes de reporting et d'intégration….

Pourquoi les numéros de séquence ne sont pas chronologiques

Imaginez le scénario suivant :

Étape 1 : Le pod d'interface 1 réserve les valeurs : 1, 2, 3, 4, 5

Étape 2 : Le pod d'interface 2 réserve les valeurs : 6, 7, 8, 9, 10

Étape 3 : Un utilisateur avec une session sur le pod d'interface 2 crée un ordre de travail

Étape 4 : Quelques instants plus tard, un utilisateur avec une session sur le pod d'interface 1 crée un autre ordre de travail

Le résultat :

Si vous triez par ID, l'ordre de travail UI2 semble plus récent, mais en réalité, il a été créé avant l'ordre de travail UI1.
‍

Les valeurs de séquence restent uniques, mais elles ne représentent plus l'ordre de création réel.

Pourquoi est-ce important

De nombreux utilisateurs utilisent sans le savoir les identifiants d'enregistrement comme raccourci pour répondre à des questions telles que :

• Quel est le dernier ordre de travail ?

• Quelle demande de service a été créée le plus récemment ?

• Quelle est la transaction d'inventaire la plus récente ?

• Quel actif a été ajouté en dernier ?
  ‍

Dans un environnement MAS multi-pod, ces questions ne peuvent pas être résolues de manière fiable en utilisant la valeur de séquence la plus élevée. Cela peut entraîner des rapports, des tableaux de bord, des intégrations, des migrations de données et des résultats d'informatique décisionnelle inexacts.
‍

Je suis certain de ne pas être le seul à avoir utilisé par le passé une variante de la requête ci-dessous pour obtenir la valeur la plus récente :

select * from <table>  
where <column> = ‘<value>’ and   
<table unique id> = (select max(<table unique id>) from <table> where <column> = ‘<value>’) 

Pourquoi ROWSTAMP n'est pas la solution

Certains, dont moi, ont tenté d'utiliser ROWSTAMP comme alternative.
‍

Cela pose un problème différent, car ce champ change également chaque fois qu'un enregistrement est mis à jour.
‍

Par exemple :  

Si vous triez par date de mise à jour (ROWSTAMP), WO10001 semble plus récent alors que WO10002 a été créé après.
‍

Cela rend les champs basés sur la mise à jour peu fiables pour identifier l'ordre de création initial.

Que faut-il utiliser à la place ?

La bonne approche consiste à utiliser un horodatage de création immuable.  
‍

Voici quelques exemples :

• Date de création

• Date et heure de création

• Champs d'audit créés par le système

• Autres colonnes d'horodatage en insertion seule
  ‍

Une règle empirique utile est la suivante :

Utilisez l'ID pour l'identité : l'identifiant généré par séquence identifie de manière unique un enregistrement.

Utilisez l'horodatage pour la chronologie : les horodatages de création indiquent quand un enregistrement a réellement été inséré.

Utilisez les deux pour un classement stable : lorsque plusieurs enregistrements partagent la même granularité d'horodatage, combiner l'horodatage et l'ID permet d'obtenir un classement déterministe.

Résumé

À mesure que les déploiements de MAS Manage exploitent davantage Kubernetes et plusieurs pods pour la scalabilité, les hypothèses qui fonctionnaient dans les environnements Maximo hérités sur serveur unique deviennent moins fiables.
‍

Les numéros de séquence ont été conçus pour résoudre un seul problème : l'unicité.
‍

Ils n'ont jamais eu vocation à servir de preuve de l'ordre de création.
‍

Si votre besoin métier consiste à déterminer l'événement le plus récent, fiez-vous toujours à un véritable horodatage de création plutôt qu'à un identifiant généré par une séquence. Cela garantira que vos rapports, intégrations et décisions opérationnelles reposent sur la réalité plutôt que sur l'ordre aléatoire de valeurs de séquence mises en cache.

‍