Inconsistent ODATA Query Results in DX NetOps Performance Management
search cancel

Inconsistent ODATA Query Results in DX NetOps Performance Management

book

Article ID: 230784

calendar_today

Updated On:

Products

CA Performance Management - Usage and Administration DX NetOps

Issue/Introduction

Query filtering with qosclassmap/Name (or DisplayName) works when time range with hours is left out.  Adding time range (much include hours) causes filter to be ignored.

This query works:

http://<DA_HOST>:8581/odata/api/qosclassmapmfs?$apply=groupby(ID, aggregate(im_NetworkUtilization with percentile95 as Value))&$orderby=Value desc&$top=10&$skip=0&top=10&$expand=device,qosclassmap&$select=device/Name,device/PrimaryIPAddress,Value,qosclassmap/Name&$filter=((startswith(tolower(groups/Name), tolower('z_95API')) eq true) and (Value gt 10) and (substringof(tolower('Voice'), tolower(qosclassmap/Name)) eq true))

This query fails. It included more items than the filter seeks to include in the resulting data.

http://<DA_HOST>:8581/odata/api/qosclassmapmfs?$apply=groupby(ID, aggregate(im_NetworkUtilization with percentile95 as Value))&$orderby=Value desc&$top=10&$skip=0&top=10&&resolution=RATE&period=1m&bh=Mon-Fri 9:00-17:00&$expand=device,qosclassmap&$select=device/Name,device/PrimaryIPAddress,Value,qosclassmap/Name&$filter=((startswith(tolower(groups/Name), tolower('z_95API')) eq true) and (Value gt 10) and (substringof(tolower('Voice'), tolower(qosclassmap/Name)) eq true))

Environment

All supported DX NetOps Performance Management releases

Cause

The working query checks that the data time stamp (tstamp) is between 2 numbers AND the item_id is in a LIST.

The NON-working one checks if tstamp is between 2 numbers for all necessary checks, 22 in this example, and then an item_id check.  The item_id check is actually ignored because as long as ANY OR passes, it's TRUE. As a result we include the row in the results.

Resolution

Addressed by defect DE523597. It is resolved and included in the r21.2.7 release. Upgrade to that release or newer to resolve this.

There is no known workaround. The fix required is hard coded in the existing software.

The Fixed Issues list for the r21.2.7 release shows the following for DE523597.

Symptom: OpenAPI could return an inconsistent metric data when business hours applied to a query.
Resolution: With the fix OpenAPI would return correct data with business hours applied to a query