In order to get that information (which I'm supposing somebody introduced that info on CMDB -> Reconciliation Manager forms) you'll have to study your "Identification and Merge Activity" job. This Job is normally formed by two activities: Identification and Merge.
Well, here, ath the hightest level, you limit what you want to compare between Datasets, creating the necessary Identification Groups (Reconciliation Groups) and the Identification Rules (for each Identification Group).
Here is where you define your Dataset Merge Predecence Set for your Source Dataset(s).
Suppose you've MS.IMPORT.SMS, BMC.ASSET and BMC.ASSET.SANDBOX Datasets.
Your Job's goal will be identify Computer System CI's on this Datasets and subsequently merge possible changes on BMC.ASSET Dataset, thus providing a unique view for each Computer System CI.
Identification activity, as said, seems clear. But for the Merge activity, you'll have to define Dataset Precendence Groups:
- MS.IMPORT.SMS Precedence (Precedence=100)
- BMC.ASSET.SANDBOX Precedence (Precedence=100)
Here, following our sample, we can see the following:
- BMC.ASSET is the dataset with highest precedence, with the exception of particular attributes we get from SMS (through MS.IMPORT.SMS dataset). This way, we could guarantee that these SMS's attributes will be used during the reconcilliation process
- For the rest of the attributes, their reconcilliation will depend on the dataset's precedence they belong to
The following table could help us understand precedence (again, for our sample):
Due to the fact that CI's are manually created using AST% forms (i.e. creation of CI's directly from SMS is not allowed), BMC.ASSET dataset will have the highest precedence.
Will contain a copy of BMC.ASSET dataset. No attribute should be merged into BMC.ASSET, thus BMC.ASSET.SANDBOX dataset’s precedence should be low.
Attribute TokenID is necessary to store SMS’s Resource ID value (in order to being able to get back TotalPhisicalMemory and CPUSpeed, attributes that are on other different SMS tables).
Other attributes, like LastScanDate, need also to have a high precendence on MS.IMPORT.SMS dataset.
But, this dataset itself, shouldn’t have a high precedence because fields like Product Categorization tiers, Serial Number,… are alrealdy populated and the merge activity would overwrite their actual values.
Between brackets, on Precedence column, appear the names that our datasets have on BMC® Atrium® CMDB 2.0 Concepts and Best Practices Guide (Page 97): A and B, source datasets and C, destination dataset.
Finally, our Default Merge Precedence Set:
And, our Reconcilliation Activity:
Well, so far... I hope you understand better "where to look".
If you don't have the aforementioned document, I could send it to your mail. Let me know.
Thank you for the in-depth analysis of the Reconciliation Jobs. My question I need answered can come from retrospect of previous jobs, however, I would like to know where the Precedence Value is stored in order to reset the BMC.ASSET dataset, once all is said and done.
Example. Tons of datasets with dataset/class/attribute precedence as high as 900 have been merged into the BMC.ASSET dataset.
We would want to reset the value to something like 500 across the board(dataset, class, or attribute level).
The precedence value has to be stored somewhere. Otherwise, when you reconcile the next dataset/class/attribute, the merge precedence has nothing to compare against.
As far as I know, you can edit Dataset precedences from within Precedence Group Information.
To change Attribute precedences, select the Dataset Precedence Group and update the attributes you need.
I wouldn't guarantee you could do a massive update...
Something says me you'll have to work dataset by dataset and, within a dataset, attribute by attribute.
Or, like you say, identify the tables that store that preference information and update at DB level (Risky business?)
Thanks Bjorn. I guess that this is just one more mystery with this system. We have been running into them left and write. From workflow running anonymously in the backgroud updating records, to understanding the cross tool functionality, and how one tool being modified has a major effect on the other.
If anyone can help, please post. We do have a ticket into BMC addressing this issue.
Justin, the following may help. Not sure if you are already across this detail but here goes.
1. When RE runs a merge against a target dataset. it updates the field called Attribute Data Source List to record the fields it is updating and the data set that has contributed the value, based on the precedence rules evaluated for the current job. You can find this field on the General tab for all CI classes. Note that it doesn't store the precedence weighting that applied in making its merge decision. You need to go back to the dataset merge precedence set to find out which merge rules applied. So if you look in this field for a BMC Computer System class CI you might see
or something like that (it will typically be alot more than just that)
What this means is that when the last merge job updated them, field ids 3001020,127373,38438783 retained their values in BMC.ASSET due to higher precedence weightings for that dataset, and field 30001021 was updated from MS.IMPORT.SMS due to a higher precedence weighting for THAT dataset.
2. As mentioned above, when you see that MS.IMPORT.SMS did contribute the value for field id 30001021, you can't see what the actual winning weighting was, just that it won. All you know is that MS.IMPORT.SMS evaluated for this field higher than BMC.ASSET (and any other datasets also being merged if there were more than one). To find out what the winning weighting was, look at the RE job in question, and check the dataset merge precedence set definitions. This will show you which precedence group was associated with MS.IMPORT.SMS for this RE job, and hence you can check that group's configuration to determine the precedence weighting applied.
Just to clarify. The precedence values/weightings ARE held in the 'database'. They are stored in each Precedence Group where they can be edited/tuned. The Precedence Set associates a Precedence Group (where the precedence values are defined) and a dataset (to which these precedence values will be applied in the merge job).
I'm waking this thread up again to ask a question about an interesting situation I've come across.
Looking at a 7.6.02 ITSM environment, there is no precedence group defined that references BMC.ASSET itself. There are lots of datasets referenced in various groups, including the Asset sandbox etc, but not one entry for BMC.ASSET dataset. This would probably be OK if the system was exclusively using the Sandbox for all changes, but in their environment, this is not enabled, and changes are permitted via the AST forms (and the BMC.CORE forms as well for that matter).
What's worrying me is this. Say a ComputerSystem CI is added manually through an AST form. A little later, maybe SCCM discovery comes along and an attempt to identify and merge data happens. The SCCM dataset has a number of ComputerSystem attributes defined in a precedence group as say weighting 500. The overall ComputerSystem class weighting is set at, say, 100.
When the merge happens, RE can work out what each attribute or overall class weighting needs to be from the correctly defined SCCM dataset precedence group, but how does it decide what the existing BMC.ASSET CI and attribute weightings are when it decide to merge CIs?? How does it decide whether to use a value from the SCCM dataset or not?? It seems there is undefined precedence for BMC.ASSET at this stage?
Funny thing is, the merges do happen, and the desired SCCM values (and generally ONLY those) get through to BMC.ASSET.
Can anyone explain this? Is there some magical default precedence value for BMC.ASSET in the absence of an explicit one?
Hi Carey, if the jobs were created using atrium:console then there is high possibility that some of the artifacts or cached files are getting used even after deleting the entries.have seen that happening so we were advised to use cmdb:console instead of atrium:console to create / modify recon merge defs.
is the environment server grouped..?
but it would be really weird if you are creating jobs from cmdb:console and still bmc asset precedence works magically . Sorry, don't have 7602 documentation or a 7602 environment unfortunately to replicate this....
By default the BMC.ASSET has a precedence value of 100
-This is how I would confirm that
-In the default merge precedence sets - there are many precedence sets which has a precedence group and dataset mapping.
Attachment PrecedenceGroup1 lists the available Precedence groups (erroneously labelled as Precedence Sets) mapped to a Dataset
-You would see BMC.ASSET mapped to a group 'Atrium Explorer - Copy to Sandbox - BMC RE005056af27fa0cAQTA0O_TBwQQMa'
- If you edit this group (erroneously labelled - edit precedence set), you would find the Dataset Precedence Value listed as 100, as seen in attachment PrecedenceGroup2
- Any value greater/equal to this value would cause a Merge to happen in the BMC.ASSET dataset.
Thanks for this information. I think that the value of 100 for the BMC.ASSET precedence WILL indeed apply if that precedence association was used in a recon job - but only at that point. If I create a new CI directly in BMC.ASSET (no sandbox, etc), there is no implied precedence I don't think. i.e. look at the attribute data source list for the CI and it is empty immediately after creation. Run a recon job that updates that CI, and you will see attribute data source list showing how some fields were updated (i.e. from which data set), but I don't see hoe the recon engine was able to make that call, without BMC.ASSET being explicitly mentioned somewhere in the precedence set being use for the recon. merge job. i.e. we use the BMC Default Merge Precedence Set shown in your example, which has been extended for new datasets we use, BUT there is no entry for BMC.ASSET in that precedence set. This is my issue.
See screen shot above. The precedence sets are sorted alphabetically by dataset name - no BMC.ASSET