Thanks a lot Peter.Your post really helps. I had an understanding that we can transform the recon rules according to our way to whatever depth. & that was the reason, I gave relationship identification rules also, just to make sure that I dont miss on any of the data of test dataset.
Peter Romain-2 wrote: > > Hi, > > What you describe is the behaviour I would expect. > > When a Computer CI is related to an IP CI via a weak relationship (hosted > access point is weak) then the Computer and IP are treated as a composite > object and not individually. > > The IP in the test dataset will only be reconciled against an existing IP > in > the production dataset if they are both related to the same computer. > > Try your test again using strong relationships between the computer and IP > CIs and you should see the behaviour you are expecting (though you should > revert to the hosted access point relationship after testing). > > I don't understand why you are identifying relationships. Just create > identification rules for the main CI's and the relationships will take > care > of themselves. > > Cheers > > Peter > > > -----Original Message----- > From: Action Request System discussion list(ARSList) > [mailto:[email protected]] On Behalf Of rmdusr > Sent: 19 January 2011 13:27 > To: [email protected] > Subject: issue in setting up reconciliation rules.. > > Hi, > > Env: ARS 7.5 patch4, Atrium CMDB 7.6 patch1,ITSM 7.0.3 patch9 > > I will try best to explain this complex issue in simple way! > > I am making a custom recon job, which identifies a test dataset(containing > computer system , IP Endpoint, LANendpoint, Hosted > accesspoint(relationships > between comp-IP & comp-LAN). > > > Idea is to update the existing CIs & create the new ones. > > > I have set 'identification rulesets' for each CI class based on AssetId ( > 'AssetID' = $AssetID$) > > For the relationship class(hosted accesspoint), my identification rule set > is ('Source Reconid' =$SourceReconid$) & ('Destination Reconid' = > $Destination Reconid$). > > > Now if my test dataset has Computer System C1, it checks against > Production > dataset's Computer system C1, & updates it. If it does not find it, it > creates C1. > > > But, this does not happen for IPEndpoint class, if CI with AssetID, say > IP1 > is already existing in prod dataset & may be related to C2 in production > dataset.When the test dataset has IP1 related to C3, C3 gets > created(because > it was not in prod dataset before) but a duplicate IP1 also gets created > in > production dataset. along with their relationship(C3--->IP1), although I > already have C2---->IP1 in the prod dataset. So, in nut shell, I have 2 > instances of same Asset id IP1(ofcourse they have different recon ids), 1 > linked to computer C2 & other to computer C3. > > > The same thing happens for LANEndpoint class. > > > I am aware of the cardinality of hostedaccesspoint is 1-Many. So, 1 Comp > CI > can have multiple IPEndpoints, but not vice versa. So, holding this > standard > architecture rule, I expect that recon job should create only new IP CIs, > & > not duplicates. > > > & talking bout relationship CIs, then if it encounters an IP1 which is > already related to a Computer C2, it should not create a second > relationship > > > C3--->IP1. > > Any help! > > -- > View this message in context: > http://ars-action-request-system.1093659.n2.nabble.com/issue-in-setting-up-r > econciliation-rules-tp5939613p5939613.html > Sent from the ARS (Action Request System) mailing list archive at > Nabble.com. > > ____________________________________________________________________________ > ___ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > _______________________________________________________________________________ > UNSUBSCRIBE or access ARSlist Archives at www.arslist.org > attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are" > > -- View this message in context: http://old.nabble.com/issue-in-setting-up-reconciliation-rules..-tp30709825p30716897.html Sent from the ARS (Action Request System) mailing list archive at Nabble.com. _______________________________________________________________________________ UNSUBSCRIBE or access ARSlist Archives at www.arslist.org attend wwrug11 www.wwrug.com ARSList: "Where the Answers Are"
