The “Object cannot be saved” error
A client hired me to do a bit of house-cleaning and provide minor enhancements for their Maximo system. It has some pieces of buggy Java code and I took the opportunities to de-customize the Java code by rewriting the logic with Automation Script. For one piece of logic, it worked well in the Development environment. However, when deployed to Production, it did not work.
The automation script is triggered when the user saves a record, but it executes at the post commit launch point. Thus, this script does not give any error on the frontend. However, there is an error “BMXAA4017E object cannot be saved with the data that was provided” in the SystemOut.log file. The error came from the mbo.checkQualifiedRestriction method
Background Information
The BMXAA4017E error is a common error. It often occurs because of a QUALIFIED rule setup in security restriction preventing an user to interact with data he/she should not have access to.
However, this client has an interesting environment with four satelite Maximo servers located in Antarctica synchronized to a central server via satellite using a data sync solution provided by SRO. Although the number of active users is low, they have 500-600 users across nearly 20 logical sites. There are many data restriction rules configured at various levels: global, site, security group etc.
This issue gave me a chill down the spine during the deployment to Production because I simply couldn’t think of where to start looking. When I was almost announcing it a failed deployment, a random thought came up and it helped me solve the problem.
Problem and Solution
In short, the problem is, to update a record, I fetched the MboSet from the database using the MXServer.getMboSet() method. I passed in the SystemUserInfo to this method as I always do, thinking it is linked to the MAXADMIN account, and it has the ultimate access right. Below is the code:
That is where the problem comes about, that “SystemUser” profile does not belong to any Security Group or listed in any security restriction rules. One of those rules must have failed and caused the error. To fix it, I changed the code to use the current logged in user’s security profile as follows:
To be honest, I still haven’t figured out why the same code using SystemUserInfo
works in the DEV and TEST environments, and not works in PROD. But as an engineer, not a scientist, I guess it is ok to not knowing the Why sometimes. As long as it works, everyone is happy 😊
