cancel
Showing results for 
Search instead for 
Did you mean: 
cancel
1166
Views
1
Helpful
2
Replies

Receiving HTTP 500 when trying to use groups/userDefinedGroups

Doug Byrd
Level 5
Level 5

I'd like to start by saying that I'm new to programmatic networking, but am familiar with programming principles.  We are currently running Prime 3.0.2 with the latest device pack.  I'm able to poke around the APIs and gather basic information, however, when I try to use groups/UserDefinedGroups as described in the API documentation, I receive the following error:

Request: https://PRIME/webacs/api/v1/op/groups/userDefinedGroups

<?xml version="1.0" ?>

<errorDocument>

    <httpResponseCode>500</httpResponseCode>

    <httpMethod>GET</httpMethod>

    <exception>java.lang.NullPointerException</exception>

    <uriPath>op/groups/userDefinedGroups</uriPath>

    <queryParams>{}</queryParams>

</errorDocument>

After poking around this forum, I saw one reference that even though some attributes are marked as optional, at least one is required so I've tried the following, as well:

Request: https://PRIME/webacs/api/v1/op/groups/userDefinedGroups?.groupType=NETWORK_DEVICE

<?xml version="1.0" ?>

<errorDocument>

    <httpResponseCode>500</httpResponseCode>

    <httpMethod>GET</httpMethod>

    <message>com.cisco.xmp.web.PresentationException: Unrecognized control query-param groupType with value NETWORK_DEVICE.-PRS-108</message>

    <exception>com.cisco.xmp.web.XMPWebApplicationException: com.cisco.xmp.web.PresentationException: Unrecognized control query-param groupType with value NETWORK_DEVICE.-PRS-108</exception>

    <uriPath>op/groups/userDefinedGroups</uriPath>

    <queryParams>{.groupType=[NETWORK_DEVICE]}</queryParams>

</errorDocument>



Request: https://PRIME/webacs/api/v1/op/groups/userDefinedGroups?.noAlarms=true

<?xml version="1.0" ?>

<errorDocument>

    <httpResponseCode>500</httpResponseCode>

    <httpMethod>GET</httpMethod>

    <message>com.cisco.xmp.web.PresentationException: Unrecognized control query-param noAlarms with value true.-PRS-108</message>

    <exception>com.cisco.xmp.web.XMPWebApplicationException: com.cisco.xmp.web.PresentationException: Unrecognized control query-param noAlarms with value true.-PRS-108</exception>

    <uriPath>op/groups/userDefinedGroups</uriPath>

    <queryParams>{.noAlarms=[true]}</queryParams>

</errorDocument>

Is there something I'm doing wrong is is this something with the API?  I'm trying to create location groups based on site codes contained in device hostnames (200+) so I was using this to see what the format would be.

*Edited to remove hostname*

2 Replies 2

Spencer Zier
Cisco Employee
Cisco Employee

The groupType and noAlarms parameters for these resources are not preceded with a ".", so that's why you're receiving the last two errors.  As far as the first error, we did see one issue where this service would return a 500 NullPointerException error, but we root caused that issue and fixed it all during the development of 3.0.0.  I'm not familiar with what might be causing this 500 error you are seeing now.

Has this behavior just started happening recently?  After applying a patch?

If you're still seeing this behavior can you please do the following: (1) login to the UI (with administrative) privileges and go to Administration > Logging; (2) reproduce the 500 error; (3) download the logs just after reproducing the issue; (4) contact me via email (my address is in my profile) and we can setup a secure exchange of the log bundle.

Spencer, thanks for the update! I tried without the "." (https://PRIME/webacs/api/v1/op/groups/userDefinedGroups?noAlarms=true) and it did get me the information I was expecting.  This is a viable workaround for me, as the the alarm status is not important for this task.  However, if i leave off the "?noAlarms=true" i still get a 500.

Let me reveal a little bit more about our environment.  I recently went through the process of upgrade from 2.1 Standard to 3.0.2 Pro.

The process we used was roundabout and probably a very bad way to do it.

My Process was:   v2.1 App Backup > Deploy 2.2 Std OVA > Restore v2.1 App > Inline upgrade to 3.0 > Inline upgrade to 3.0.2.  At this point I realized that, unbeknownst to me, we had purchased licenses for features only available in PRO (Assurance).  So, I then did an App Backup for v3.0.2 > Deployed 3.0 PRO OVA > Inline upgrade to 3.0.2 > App Restore v3.0.2.

I hope that makes sense.