Als Maximo -professionals gaan we er vaak simpelweg vanuit dat het record met het hoogste ID het meest recent is aangemaakt. In een traditionele omgeving met één server lijkt die aanname meestal wel te kloppen.  
‍

In IBM Maximo Application Suite (MAS) Manage kan die logica echter tot onjuiste conclusies leiden, zeker wanneer er met meerdere pods wordt gewerkt.
‍

Begrijpen hoe Maximo databasesequenties beheert, waarden in de cache plaatst en ID's toewijst over meerdere pods is essentieel voor architecten, ontwikkelaars, rapportagespecialisten en integratieteams.

Begrip van Maximo-sequentiebeheer

Maximo vertrouwt op databasesequenties om unieke identificatiegegevens te genereren voor records zoals:

• Werkorders

• Servicemeldingen

• Voorraadtransacties

• Inkooptransacties

• Aangepaste bedrijfsobjecten
  ‍

De implementatie varieert enigszins afhankelijk van het databaseplatform.

Oracle en Db2

Oracle en Db2 maken gebruik van native database-sequence-objecten. De database zelf beheert de reeks en garandeert uniciteit over alle applicatie-instanties heen.
‍

Wanneer Maximo een nieuwe identificatiecode nodig heeft, vraagt het de volgende waarde rechtstreeks op bij de database-sequence.

SQL Server

Historisch gezien gebruikte Maximo op SQL Server de tabel MAXSEQUENCE in plaats van native SQL Server-sequence-objecten.
‍

In recentere MAS Manage-releases kan SQL Server gebruikmaken van native SQL Server-sequences via het NEXT VALUE FOR-mechanisme, mits correct geconfigureerd.
‍

Ongeacht het databaseplatform blijft het hoofddoel hetzelfde:

Genereer unieke waarden efficiënt en veilig in een omgeving met een hoge gelijktijdigheid.

Delen meerdere MAS Manage-pods dezelfde sequence?

Het korte antwoord is ja.
‍

In MAS Manage maken alle pods verbinding met dezelfde gedeelde database. Hierdoor delen ze ook dezelfde onderliggende sequence-objecten.
‍

Een sequence bestaat niet onafhankelijk binnen individuele pods. In plaats daarvan:

• De sequence bevindt zich in de database.

• Elke pod vraagt waarden op van dezelfde sequence.

• De database garandeert uniciteit.

• Meerdere pods kunnen gelijktijdig records genereren zonder botsingen.
  ‍

Dit betekent dat UI-pods, integratie-pods, cron-pods en rapportage-pods allemaal waarden verbruiken van dezelfde onderliggende sequence-bron.

Wat is de cache? (Snap je hem?)

Om de prestaties te verbeteren, vraagt Maximo doorgaans niet elke keer dat een record wordt aangemaakt een nieuwe sequence-waarde op bij de database.
‍

In plaats daarvan reserveert het blokken met waarden en slaat deze op in het geheugen.
‍

Bijvoorbeeld:

• UI-pod 1 reserveert sequences 1 – 5

• UI-pod 2 reserveert sequences 6 – 10
  ‍

Beide reeksen zijn uniek omdat ze zijn toegewezen vanuit dezelfde databasereeks.
‍

Elke pod heeft nu een eigen lokale cache, waardoor records kunnen worden aangemaakt zonder voortdurend databaseverkeer.
‍

Dit verbetert de schaalbaarheid en prestaties van het systeem aanzienlijk. Hier beginnen echter veel rapportage- en integratieproblemen….

Waarom volgnummers niet chronologisch zijn

Stel je het volgende scenario voor:

Stap 1: UI Pod 1 reserveert waarden: 1, 2, 3, 4, 5

Stap 2: UI Pod 2 reserveert waarden: 6, 7, 8, 9, 10

Stap 3: Een gebruiker met een sessie in UI Pod 2 maakt een werkorder aan

Stap 4: Even later maakt een gebruiker met een sessie in UI Pod 1 een andere werkorder aan

Het resultaat:

Als je sorteert op ID, lijkt werkorder UI2 nieuwer, maar in werkelijkheid werd deze aangemaakt vóór werkorder UI1.
‍

De reeks-waarden blijven uniek, maar ze vertegenwoordigen niet langer de werkelijke aanmaakvolgorde.

Waarom dit belangrijk is

Veel gebruikers gebruiken record-ID's onbewust als een snelle manier om vragen te beantwoorden zoals:

• Wat was de laatste Werkorder?

• Welk Serviceverzoek is het meest recent aangemaakt?

• Wat is de nieuwste Voorraadtransactie?

• Welk Asset is als laatste toegevoegd?
  ‍

In een MAS-omgeving met meerdere pods kunnen deze vragen niet betrouwbaar worden beantwoord met de hoogste reeks-waarde. Dit kan leiden tot onnauwkeurige rapporten, dashboards, integraties, datamigraties en business intelligence-resultaten.
‍

Ik ben er zeker van dat ik niet de enige ben die in het verleden een variant van onderstaande query heeft gebruikt om de meest recente waarde te achterhalen:

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

Waarom ROWSTAMP niet de oplossing is

Sommigen, waaronder ikzelf, hebben geprobeerd ROWSTAMP als alternatief te gebruiken.
‍

Dit introduceert een ander probleem, aangezien dit veld ook verandert telkens wanneer een record wordt bijgewerkt.
‍

Bijvoorbeeld:  

Indien gesorteerd op wijzigingsdatum (ROWSTAMP), WO10001 lijkt nieuwer, ook al is WO10002 later aangemaakt.
‍

Hierdoor zijn op wijzigingen gebaseerde velden onbetrouwbaar voor het bepalen van de oorspronkelijke aanmaakvolgorde.

Wat kun je beter gebruiken?

De juiste aanpak is het gebruik van een onveranderlijke aanmaakdatum.  
‍

Voorbeelden hiervan zijn:

• Aanmaakdatum

• Aanmaakdatum en -tijd

• Door het systeem gegenereerde auditvelden

• Andere kolommen met alleen invoer-tijdstempels
  ‍

Een handige vuistregel is:

Gebruik het ID voor identiteit: de door een reeks gegenereerde identificatiecode identificeert een record op unieke wijze.

Gebruik het tijdstempel voor chronologie: aanmaaktijdstempels tonen wanneer een record daadwerkelijk is ingevoerd.

Gebruik beide voor een stabiele volgorde: wanneer meerdere records hetzelfde tijdstempel hebben, kan het combineren van tijdstempel en ID zorgen voor een deterministische volgorde.

Samenvatting

Naarmate MAS Manage-implementaties voor schaalbaarheid steeds vaker gebruikmaken van Kubernetes en meerdere pods, worden aannames die werkten in verouderde Maximo-omgevingen met één server minder betrouwbaar.
‍

Volgnummers zijn ontworpen om één probleem op te lossen: uniciteit.
‍

Ze waren nooit bedoeld om te dienen als bewijs van aanmaakvolgorde.
‍

Als uw bedrijfsbehoefte vereist dat u bepaalt wat er het meest recent is gebeurd, vertrouw dan altijd op een echte aanmaaktijdstempel in plaats van op een door een reeks gegenereerde identificatiecode. Hiermee zorgt u ervoor dat uw rapporten, integraties en operationele beslissingen gebaseerd zijn op de werkelijkheid in plaats van op de toevallige volgorde van gecachte reeks-waarden.

‍