thanks
rmduser wrote: > > 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..-tp30709825p30721509.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"
