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-reconciliation-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"
