Blogs

SOBRE ESTE BLOG

Welcome to the Network and Service Assurance Blog, where you can read the perspectives from network and service assurance experts. This Blog provides insights into the network and service assurance solution, as well as technical details about specific IBM

Links

TWEETS RECENTES

Enumerating the ITNM device class hierarchy for network views

ITNM categorizes devices into an 'Active Object Class', or AOC', hierarchy that helps classify devices in terms of vendor, role and model family. For example, the tree root is called 'Core' and under the root are sub-classes such as "EndNode" and "NetworkDevice" and then the various vendors under network device and so-on.

Out-of-the-box, ITNM creates a set of 'network views' based on the results of the discovery process; part of which includes the classes defined in the AOC's under the "Device Classes" section of the network view tree, such as shown in the following screenshot:-

This is great, but what if you want the tree hierarchy captured for that bit of additional context? i.e. you want the GUI to show that all Cisco26xx family devices are classified as follows in the AOC hierarchy:- Core -> NetworkDevice -> Cisco -> Cisco26xx.

So, we need a query that does two things:-

1. Traverses the ITNM AOC hierarchy recursively and somehow enumerates the parent-child relationships into something we can use in the GUIs.

2. Gets the ITNM NCIM database entityId's of the things considered to be members of the leaf-nodes of that particular part of the tree, i.e. if the tree is Core->NetworkDevice we want just members of NetworkDevice, not Core as well.

Luckily, this is pretty easy to do as you can use a cool tree traversal capability that the databases used by ITNM typically support. Note that there are various ways of doing this depending on your database platform and so check out the relevant docs. In this example I'm using Informix and its hierarchical query capability. Check out the following link for more info...

Lines 1-5 create a view called classHierarchy in the ncim schema with 'path' and 'entityId' columns, i.e. the enumerated class hierarchy and the entityId's considered to be members of the last class in the path.

Lines 6-13 define the query that drives the content of the view and it's broken down like this:-

Lines 6 & 7 pull the columns we're interested in putting into the view from the query body, in this case we're pulling 'path' from the subquery aliased as 'hierarcy' and the entityId from the classMembers table aliased as 'c'.

Lines 8-12 define the sub-query that recursively traverses the ITNM class hiearchy. In this case want the classId from the entityClass table aliases as 'ec' (for later...) and we want to create a UNIX-like directory 'path' for the tree hierarchy such as "/Core/EndNode/Linux". We can do this by using the SYS_CONNECT_BY_PATH function which recursively concatenates path elements into a single string delimited by the delimiter of your choice, in this case '/'. We then alias this string as 'path'.

Lines 11 & 12 is where the action happens regarding traversing the tree in the right order. Here's we're using START WITH to start traversal from the entityClass called 'Core' (i.e. the root node of the AOC hierarchy). We then use CONNECT BY PRIOR to step through the hierarchy, i.e. the next superclassId becomes the previous classId. We then alias this as 'hierarchy'.

Line 13 gets the associated records fro the classMembers table for each classId in the previous query aliased as 'hierarchy'.

Here's some examples of creating the view and running a test query using ncp_oql within ITNM:-

Now we need to make our new view visible to the GUI so we can define filters against it. To do this, you need to edit the $ITNMHOME/profiles/TIPProfile/etc/tnm/ncimMetaData.xmlfile which controls what the GUI shows in the structure browser and what you can search and filter against. Each entityMetaData element typically describes a set of fields from a table or view, tables to query and some search properties. Lets add an entry for our new view... using the existing entry for the mainNodeDetails view as a template is a good place to start. In this case we've added it at the end of the file and added a new dataField element for each column returned by the view.

...

<!-- ############################################################ -->

<!-- the classHierarchy view for enumerated class-path based searches -->