Two things to look at.
1. Both end points in the relationship need to be identified before the relationship itself will be identified. Looks lik ethe DB got identified OK from your screen shot, but what about the Software Server CI?
2. In you rmerge job, how have you define the Child CIs option?
What versions of CMDB are we using here?
1. Both end points in the relationship need to be identified before the relationship itself will be identified. Looks like either DB got identified OK from your screen shot, but what about the Software Server CI?
Yes, parent is previously identified and once I run the identification job it identifies the child but not the relationship between them.
What I have to do in order this to happen I have to enter an extra qualification for the relationship with it's name:
Running this way it identify the relationship correctly but if this qualification is removed the relationship is never identify.
2. In you rmerge job, how have you define the Child CIs option? I have identify it using qualification above
3. We are running on 8.1
Per my understanding once parent get identified all child should do as well and its relationships without using my extra qualification, please correct me if I'm wrong.
At this point we do not have a clue what could be the issue or if there is any setting that needs to be modified.
I would appreciate if you could give me your point of view on this issue
You are right, if both end points are identified, then generally the relationship will be as well (without needing this extra qualification).
I asked about your setting of the settings about child CIs. I was meaning the Merge Order setting for the merge activity (bottom right of the merge activity screen under Additional Parameters. This is probably NOT the issue for you since it is at Identification time that you are having issues, but wanted to check anyway.
I just ran a quick test with two CIs and a Dependency relationship between them. Without any extra qualifications, all three got identified and merged (i.e. 2 CIs and 1 relationship). This was on a 9.1 install, but that shouldn't make any difference. Let me do some more checking.
Record will not be identified if there are duplicates in the destination dataset. Check your destination dataset (BMC.ASSET most likely) if there are multiple relationships between the endpoints. Use Source and Destination Reconciliation ID values for the search.
Also run the same search in BMC.ADDM dataset. Another relationship record with those endpoints may already have been identified (potentially Marked as Deleted) so reconciliation will not identify that relationship record again.
Good Day Arto,
Thanks for your comments I reviewed this and no, there isn't any duplicates related and they are not marked as delete. Seems like on that side everything is ok but for some reason the relationship is not being taken.
Thanks Carey for reviewing and testing the scenario.
The parameter that I have in merge job is "By Class is separate transactions". But as you mentioned this shouldn't impact since I'm performing a separate job.
Thanks for keep reviewing, if you find something I can try I will appreciate it
1 of 1 people found this helpful
You need the qualification for BaseRelationship, otherwise the Identify job will only process CIs.
Hi Gustavo and Nely.
This whole area of when relationships get identified and when they don't, can be quite confusing. It also seems that either because of bugs or deliberate changes in design, that this is different between CMDB versions.
To try and start helping Nely with this, I did a really simple test. In a new dataset I create two CIs and a dependency relationship between them. I chose Dependency specifically because it is NOT defined as a weak-reference relationship.
I built a simple recon job with Generate Ids set to Yes, (knowing that the CI attributes would result in new CIs in BMC.ASSET). No qualifications, and for what it's worth I left the Merge Rules as Stand Alone. As Nely pointed out above, it's not the merge that is creating the issue, it's the identification stage.
I ran this first with both Id and Merge activities enabled, and I got the 2 CIs and the Dependency rel. create in BMC.ASSET. I didn't have to do anything for this to work as far as getting the rel. as well as the CIs.
I then rolled back the data to get rid of the BMC.ASSET side of things and ran just the ID activity to ensure things were identified as expected, and they were.
So, on my 9.1 environment, a pretty much default RE job correctly identifies (and then merges) the CIs AND the rel. No need for BaseRelationship qualification or the other qualifications that Nely is having to use.
So why does Nely have to use the relationship name in a qualification as shown above (or as Gustavo has suggested, putting in a qualification that references BaseRelationship and probably a condition like 1=1 or similar) to make this work? For my simple example, it seems to work fine without any of this. Interestingly, in the ID activity log file, I found this debug detail
Working class: BMC.CORE:BMC_Dependency
<INFO > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.0210 */ Working dataset: CWTEST
<DETAILS > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.0210 */ Getting instance ids which are not identified
<INFO > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.0210 */ Qualification: empty
<INFO > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.0210 */ Number of instances which are to be identified are <1>
<DETAILS > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.0210 */ <Chunking = 1> Start processing instance <1>
<DETAILS > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.0210 */ Identifying instances
<DETAILS > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.0210 */ Getting attribute values for <1> instances for relation's class <BMC.CORE:BMC_Dependency>
<DETAILS > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.0370 */ Started waiting for all the threads to finish
<INFO > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0370 */ Identifying instance <relationship = BMC.CORE:BMC_Dependency, instance id = AGGAAFOKEJB3EAO77W43O6MFZJORBP>
<DETAILS > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0370 */ IdentifyRelshipInstance::getMultipleInstances() sessionID: 8020528
<DETAILS > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0520 */ IdentifyRelshipInstance::getMultipleInstances() sessionID: 8020528
<DETAILS > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0520 */ Looking in other datasets for matching the relationship
<DETAILS > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0520 */ Looking in dataset <BMC Asset>
<DETAILS > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0520 */ Replaced field <400130900 = $400130900$> with 1 = 1
<DETAILS > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0520 */ Replaced field <400131000 = $400131000$> with 1 = 1
<TRACE > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0520 */ foreignOSClass[BMC.CORE:BMC_Dependency]
<TRACE > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0990 */ No matching keys found in dataset <BMC Asset>
<TRACE > <TID: 0000005656> /* Thu Dec 01 2016 17:23:35.0990 */ Setting reconciliation identity to <OI-A40A139CD4EC40D9838DE5C55F584407> for instance id <AGGAAFOKEJB3EAO77W43O6MFZJORBP> for class <BMC.CORE:BMC_Dependency> in auto-identity dataset <CWTEST>
<DETAILS > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.3020 */ Finished waiting
<INFO > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.3330 */ [PERF] Identification activity total time < 1>
<INFO > <TID: 0000005752> /* Thu Dec 01 2016 17:23:35.3330 */ Activity completed: New Activity
The highlighted code is replacing the check for a relationship with the same source and destination CI recon. ids with checks for 1 = 1??? Am I reading that right? I didn't specify that in any of my rules?
Is this a difference in 8.1 vs 9.1 behaviour?
Nely - can you build a quick basic recon. job as I did (see above reply). Just to see if in the most simple case, your environment is behaving the same as mine?
i.e. in a dataset that is currently empty, create two computer system CIs, Relate them with a Dependency relationship. Build a standard recon job to identify against BMC.ASSET (and just define the CI attributes to ensure there is no match in BMC.ASSET). Run the job and see if you get the identification part working as expected?
3 of 3 people found this helpful
I will explain WHY you need to have a qualification for BaseRelationship.
If you check the screenshot of Nely:
Imagine the qualification with only the SWS and the DB rules.
You are saying, please identify my CIs from the Software Server class which pass this qual (name = oracle bla bla), and also please identify the Database CIs that have name = APOLLOP
That is IT. There is nothing ELSE to be identified. Why would RE assume that you want to identify Relationships?????
If we would assume every omission in the rules indicates that you need processing then we should also identify all the other CI classes, like computer system, printer, mainframe, etc. etc. simply because they don't show up in the qualification.
Now... if you do not use ANY qualifications, as in Carey's test, then that is different, you do not need to specify anything on BaseRelationships because by default we identify ALL CIs and ALL RELs.
Hope it is clear.
Thanks for the further explanation. So what we are saying is that if you add ANY sort of qualification for CIs, you must add an explicit additional qualification to get the relationships as well (since RE will take your CI qualifications literally ) What Nely had done was to specify just the relationships with Name='DEPENDENCY' which probably works for this case but is not very generic.
Looking at the log file section I added above, when there is no qualification (as in my test), there is workflow clearly then that changes the normal checks for matching source and destination RE IDs to a simple 1=1 test (i.e. always true therefore always include all relationships). Is that a correct explanation?
And, if it is correct, then a generic way of ensuring all rels. are included when you specifcy other qualification rules, would be to specify Class=BMC_BaseRelationship and Qualification rule 1=1??
Yes to all of your questions!!!
PD: I agree the dependency rule is very specific to the use case.