Share This:

Today's topic is about data quality and CMDB data reconciliation. Data management is impacted when data can not be verified and tracked to its source. We're in the business that seeks data quality and often rely on data auditing to see when a change was made. By whom, when, and why. However, in some cases this may not be as clear cut as it seems by just looking at the change history captured by the AR auditor.


There are less known ways of back tracking changes made to CMDB records, known as CIs and Relationships. 
This blog post is about hidden fields in the CMDB application that can help me understand when and how a record was updated.

 

Let's say that the MarkAsDeleted field has been getting set to a Yes value, while the source record is still set to No.
In such case you'd likely want to know what is making the change and you suspect Reconciliation Merge activity as the culprit.
You can follow markers back to it's source to see if it really is Reconciliation.

 

Usually the inquiry begins by looking at the recon logs. Logs set to debug level will show what value is being updated.
Value of 0 is No and 1 is Yes.  The log can also indicate that MarkAsDeleted is not being updated at all.


For example. Log shows:

Attribute   : MarkAsDeleted
Value       : 0  << this shows the default value of MarkAsDeleted as No.
From Dataset: BMC.ADDM

 

In this case we'd want to know "when" exactly did the change occur. I can find the proof by looking at the CI itself. Was it reconciliation doing it? Has it merged the CI with a value for MarkAsDeleted that equals Yes ?

 

Here is how to research it:

 

Find the CI in BMC.ASSET dataset that was modified to MarkAsDeleted = Yes and look at the LastModifiedBy value.

Is it "Remedy Application Service" ? If yes, then it could have been Reconciliation, but also Normalization or even AtriumIntegrator using that account.

I am going to need stronger evidence than that. So, my next step is to look in the AttributeDataSourceList field. This field has the footprint of the last merge. It includes the source record Dataset Id and a list of Field Id's that "won" the precedence contest from that dataset. If you see BMC.ADDM followed a list of id's that include the number "400129100" (MarkAsDeleted) in the list then you can assume that the field was updated during the last merge. But there is no guarantee that the value was Yes or No at that point.

 

attributedatasourcelist.png

 

But we can do better than that.

 

1. Run an AR Report to get the value from a hidden field named as LastREJobrunID.

 

ReportLastReJobrunId.png

 

This field is defined as follows in Attribute Definitions form:

Attribute Name* : LastREJobrunId
Data Type* : Character
Field ID : 490001289
ForeignKeyID (Class GUID) : BMC_ASSETBASE
instanceId : CMDB_ATTR_ID_LAST_REJOBRUN_ID
Namespace : BMC.CORE

 

LastREJobrunId.png

 

2. Take the LastREJobrunId value from the CI that was changed, go to form "RE:Job Event" and search it using the value from step 1 using the field named: Job Run Instance Id*.
The result should give you about 3 or so records. One record for each activity and one record for the log location.

 

REJobEvent.png

 

 

3. Take a look at the date range of these activities and see if the ModifiedDate of the CI fits within the activity related to Merge. These records will have a value in "ActivityName" that describe which activity has created them. If the Create Date and Modified Date is outside of the date range of Modified Date of the CI then it was not reconciliation that has set the value. You can stop here because reconciliation simply did not do this. If the value in LasModifiedBy is Remedy Application Service, then the data could have been modified by some other method like Normalization or AtriumIntegrator. However, if the Modified Date is in synch and within the range of the LastJobREId then this record has not been modified by anything else since it was merged into BMC.ASSET dataset.

 

REJobEventAndCS.png

 

If you do find that the Modified Date of CI does fit within the Create Date and Modified Date then it was Reconciliation that did it and you'd see this captured in debug level logs.

 

On the other hand of the investigation did not show that the record was modified within that range of Create and Modified Date in Reconciliation Job Events then some other method was used to make the change.