cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
406
Views
9
Helpful
2
Replies
Highlighted
Beginner

InventoryDetails API call is missing udiDetail element for wireless controllers

Hey!

I recently started writing a script to pull inventory data from a PI 3.1 and noticed that an API call to IP/webacs/api/v1/data/InventoryDetails?.full=true is not returning an udiDetail XML element for wireless controllers.

Therefore, you can't get a serial number and device model ID from that data and have to manually call IP//webacs/api/v1/data/WlanControllerDetails?name=$controllerName for each device to get the missing data.

As this is not documented and all data for the udiDetail element would be available, I consider this a bug and would ask for a fix.

Kind regards!

Everyone's tags (1)
1 ACCEPTED SOLUTION

Accepted Solutions
Highlighted
Cisco Employee

Re: InventoryDetails API call is missing udiDetail element for wireless controllers

A couple points: you can make calls to the WlanControllerDetails resource to get pages of info per request rather than one controller per request (for example, /webacs/api/v1/data/WlanControllerDetails?.full=true&.maxResults=500).

We are aware of this limitation and how it's cumbersome (see CSCvb73710).  The reason we don't show UDIs for WLCs in the InventoryDetails resource is due to performance and historical reasons.  Serial numbers for WLCs are not stored in the same place as they are for routers and switches; historically, this is due to the fact that WLC management functionality came from Cisco Wireless Control System (WCS) and functionality for wired device management came from Cisco Network Control System (NCS).  The two products modeled some information differently, and those differences still exist in parts of Prime Infrastructure.  We could change the InventoryDetails resource to pull data from the two different sources, but when we've experimented with this in our large-scale test environments the response time was severely degraded.

The good news is that the team responsible for wireless device inventory is taking up work currently targeted for the next major release of Prime Infrastructure (3.2) that will unify these disparate models, and allow us to report UDIs for WLCs via the InventoryDetails resource without negatively impacting performance.

View solution in original post

2 REPLIES 2
Highlighted
Cisco Employee

Re: InventoryDetails API call is missing udiDetail element for wireless controllers

A couple points: you can make calls to the WlanControllerDetails resource to get pages of info per request rather than one controller per request (for example, /webacs/api/v1/data/WlanControllerDetails?.full=true&.maxResults=500).

We are aware of this limitation and how it's cumbersome (see CSCvb73710).  The reason we don't show UDIs for WLCs in the InventoryDetails resource is due to performance and historical reasons.  Serial numbers for WLCs are not stored in the same place as they are for routers and switches; historically, this is due to the fact that WLC management functionality came from Cisco Wireless Control System (WCS) and functionality for wired device management came from Cisco Network Control System (NCS).  The two products modeled some information differently, and those differences still exist in parts of Prime Infrastructure.  We could change the InventoryDetails resource to pull data from the two different sources, but when we've experimented with this in our large-scale test environments the response time was severely degraded.

The good news is that the team responsible for wireless device inventory is taking up work currently targeted for the next major release of Prime Infrastructure (3.2) that will unify these disparate models, and allow us to report UDIs for WLCs via the InventoryDetails resource without negatively impacting performance.

View solution in original post

Beginner

Re: InventoryDetails API call is missing udiDetail element for wireless controllers

Thanks a lot for the information and the better workaround!

I changed my script, works fine and faster now, and I'm looking forward to the change in 3.2.