Maximo and Data Integrity – Alert

Maximo location restructure through standard and common data loading tools can cause data integrity issues. This article demonstrates how Maximo commits data changes despite system alerts and rollback

This article uses one of the scenarios where Maximo data integrity might be compromised. Please contact our professional services for deeper analysis and solutions.

Who Is At Risk?

A low risk with high impact has been identified by Seifware Inc. when location restructure data is loaded in Maximo. The data integrity might be compromised when it is loaded through MIF using a single batch or through a data loading process such as migration manager.

What is the Issue?

When a location hierarchy is changed through a single data loading batch, Maximo may commit database changes before the full process is completed causing part of the data to be saved and the rest to be rolled back.

How to Reproduce the Issue?

This issue can be easily reproduced using Maximo standard MIF tool. In this example, we will be using only two records in a single batch. However, the same issue can be reproduced with more than two records showing that all the data will be saved/committed except the last record in the batch:

1. Create an object structure to move locations and call it “DCMMOVELOC”. Create an enterprise service and attach it to the external system that uses XML files
2. Using Maximo demo version, create a location (LOCTOP) under NEEDHAM location in the primary system
3. Create two locations (LOC1 and LOC2) under the LOCTOP location in the primary system
4. From the external system, locate the enterprise service that was added in the first step and import the attached XML file to move LOC1 and LOC2 from LOCTOP to NEEDHAM locations in a single XML file/message. Note that the XML introduces an invalid location “NEEDHAM1” on the second entry to simulate an error. Since this is a single XML message, Maximo should rollback all changes rather than committing the first and rolling back the second:
5. Investigate and confirm the issue by querying both locations (LOC1 and LOC2) and notice that LOC1 is moved to NEEDHAM location while LOC2 is not:

How to Resolve the Issue?

The root cause of this issue is in the “LocHierarchy” Maximo core class that commits transactions before all records are saved as part of a batch/set. It is important to be aware of this limitation and related consequences and avoid assuming that if an error is raised within a single XML message/file, the whole message/data batch is rolled back. Seifware Inc. is working on a data change management solution and details will be released soon. Stay tuned!

Attachments

MoveLocsXml

Updates

Maximo DCM resolves the data integrity issues that may arise from data loading. Click here to explore.