Hi Kevin,
We have done several integration using EIE 7 and CMDB 2.
The only method that really makes sense is to create a separate dataset (Cisco.Import.Ciscoworks) that you import to. Then reconcile that dataset with the primay data set (BMC.ASSET). There are several reasons for this.
1. If you import directly to BMC.ASSET, you may not know the the source of the data
2. Any failed import will leave you with partial data and corrupt BMC.ASSET
2. Any failed import will leave you with partial data and corrupt BMC.ASSET
3. With reconcile rules you can assure that precedents are handled - Is Ciscoworks always right on every value or are there times when existing data should remain?
4. Matching entries. If you use reconciliation rules, you can match data that was originally entered from other sources through much better query capabilities than directly within EIE.
As for extending the data model for a separate dataset. The only reason to extend the data model is if you need extra classes or attributes stored in your CMDB. Otherwise each dataset uses the same classes with just a different value in the DatasetID field. All the forms built on top of the CMDB allow you to filter based on dataset so you only see the data you desire, for example BMC.ASSET in your asset application. There is one slight except to this rule - We suggest adding these attributes to BMC_BaseElement for each dataset you plan to integrate via EIE -
ApplicationParentID (example - CiscoParentID, SMSParentID, etc) - to store the consistent ID/key of the computer system as it is stored in the vendor application
ApplicationChildID - to store the consistent ID/key of the component/software as it is stored in the vendor application
ApplicationReconcile - A field to hold the value EIE uses to determine if an update is needed (from the options tab where it asks you to specify a field)
The reason you need these values is so you know the source of the information and can reconcile to it once it has been merged. The reason for a separate set for each integration is because you may have multiple datasets updating a given BMC.ASSET entry, once you have reconciled and merged the data, this acts as breadcrumbs to go back and find it again. Also, if you ever decide to federate to a source and get additional information,this will provide the link to the exact instance in the vendor/3rd party application.
-------- Original Message --------
Subject: Re: Getting Ciscoworks data into CMDB 2.0
From: Kevin Murray <[EMAIL PROTECTED]>
Date: Tue, September 26, 2006 8:06 am
To: arslist@ARSLIST.ORG
Hi Jack,
One further query pertaining to your Ciscowork/CMDB integration...
Using EIE, did you populate the Production dataset (classes) directly or
were you able
to populate a staging dataset and run reconciliation between the Cisco
dataset and ANO? If you used a staging
dataset,did you have to create custom form(s) or were you able to use
existing CMDB staging forms.
Any insight appreciated.
I have to do something similar with Ciscoworks over the coming months (among
other non-BMC discovery tools)
Thanks in Advance,
Kevin
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] Behalf Of Covert, Jack
Sent: 22 September 2006 16:26
To: arslist@ARSLIST.ORG
Subject: Re: Getting Ciscoworks data into CMDB 2.0
Hi Byron. I answered this in my other email but you have to find it.
We kept our use of classes fairly basic and for the most part, out of
the box (minus an attribute here and there). We further classified CI's
by using CTI's, which we populated from information in the tool. So for
the network hardware, I set the Category and Type to static values and
the item to a value I got from Cisco Works (router, hub, etc.).
An important note might be that we only did relationships for the first
level of the network, once you get beyond that it's a cob-web with
relationships all over the place and it's value is limited. That's what
we use tools like SMARTS and Cisco Works for.
Hope this helps.
Jack
-----Original Message-----
From: Action Request System discussion list(ARSList)
[mailto:[EMAIL PROTECTED] On Behalf Of Dawe, Byron
Sent: Friday, September 22, 2006 6:28 AM
To: arslist@ARSLIST.ORG
Subject: Re: Getting Ciscoworks data into CMDB 2.0
Thanks Jack ,=20
Just one more question, how much information do you pull from Ciscoworks
and did that require adding to the existing (out of the box) classes in
the CMDB?
In Ciscoworks there is plenty of data, but not alot of this data maps to
attributes in each appropriate class in the CMDB, hence it seems to
require additional classes with extra attributes!
Or did you just stick with the out of the box classes and just populate
what you could appropriately??
Thanks again,
Byron.
________________________________________________________________________
_______
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
____________________________________________________________________________
___
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
_______________________________________________________________________________
UNSUBSCRIBE or access ARSlist Archives at http://www.wwrug.org
