UCMDB and UD Practitioners Forum (Previously CMS)
Showing results for 
Search instead for 
Do you mean 

CI identification issue

Advisor

CI identification issue

[ Edited ]

Hello,

I'm having an issue with a custom CI that is based on business_application. As per the original identification rule, the CI is supposed to duplicate instead of merge when " Two BusinessApplication instances are considered to be different if they are owned by different Party objects", which is also reflected in the ident rule itself:

                <connected-ci-condition ciType="party" linkType="ownership" isDirectionForward="false" conditionType="approveAndContradict">
                    <overlap-fixed-operator number-of-matches="1"/>

I've modified my own CIT (influx_service) to look at not party, but influx_cluster (also a custom CI based on application_system CIT):

                <connected-ci-condition ciType="influx_cluster" linkType="dependency" isDirectionForward="false" conditionType="approveAndContradict">
                    <overlap-fixed-operator number-of-matches="1"/>

Other parts of the rule are identical to the factory rule of business_application, you'll notice that I only changed the CI and link type. Given this, I believe that 2 similar influx_service CI's should duplicate/separate when they have different influx_cluster objects connected to them via dependency. I'm attaching a screenshot showing this is not what happens. The unix node highlighted with a red circle is a standalone deployment of this application and creates a different influx_cluster CI called INFLUX STANDALONE, meaning that based on the ident rule, KAPACITOR and INFLUXDB should be duplicated - STANDALONE and CLUSTER should have their own set of KAPACITOR & INFLUXDB.
I'm guessing the problem is in the rule itself, although it's copied from a factory rule. Can anyone point out what I've done wrong here?

5 REPLIES
Trusted Contributor

Re: CI identification issue

Could you post your entire Identification for this CIT? Just to ensure we're talking about the same thing.

Advisor

Re: CI identification issue

<?xml version="1.0" encoding="UTF-8" standalone="yes"?>
<identification-config type="influx_service" description="A BusinessApplication is identified by its name. Two BusinessApplication instances are considered to be different if they are owned by different Party objects, or if they have different Application ID. ">
    <identification-criteria>
        <identification-criterion>
            <attribute-condition attributeName="name" includeNullValue="false" conditionType="approveAndContradict"/>
        </identification-criterion>
    </identification-criteria>
    <match>
        <verification-criteria>
            <verification-criterion>
                <connected-ci-condition ciType="influx_cluster" linkType="dependency" isDirectionForward="false" conditionType="approveAndContradict">
                    <overlap-fixed-operator number-of-matches="1"/>
                </connected-ci-condition>
            </verification-criterion>
            <verification-criterion>
                <attribute-condition attributeName="app_id" includeNullValue="false" conditionType="approveAndContradict"/>
            </verification-criterion>
        </verification-criteria>
    </match>
</identification-config>
Trusted Contributor

Re: CI identification issue

Can you check the output from the cmdb.reconciliation.merged.log? It should state why it is merging them.

Advisor

Re: CI identification issue

I tried searching for KAPACITOR with both the name and it's global ID from merged.log - there's nothing in the log about this. PS! Logs are configured to debug.

Trusted Contributor

Re: CI identification issue

That's surprizing, if they are merging. IS there anything on this import in the other reconciliation logs? Can you run a validation where the only thing coming into the system is this data, and then grab the relevant time section of all recon logs? There must be information on this somewhere...

//Add this to "OnDomLoad" event