Experiencing Constraints with apService/accessPoint

[timway001]

I've been working with the API in Prime Infrastructure to update the information for ~1,500 access points. I'm a little frustrated. It seems I have to specify a value for the name and IP address for all 3 characters. If I send empty strings I get an error and the data other than the name does not update and I get a failure message in the Job Dashboard.

This is frustrating. It is not clearly indicated that all 3 controller IP addresses are required in the API documentation. To make matters worse I can leave the secondary and tertiary controllers and IP addresses empty in the WLC web-ui directly.

Am I misinterpreting the functionality of the API, the behavior of the the primary, secondary and tertiary fields or is the API just flatly broken? If it is broken, is it fixed in 3.1? I'm running 3.0.

Thanks,

Tim

[Spencer Zier]

This service requires that all input parameters be specified.  See a previous thread about this: Re: 500 errors on PUT with API

[timway001]

Spencer, thanks for the reply. I didn't see that thread when I was searching. If all parameters are required can you tell me what the valid null value would be for WLC controller component? In particular the controller address? I ask because in the native WLC web-ui you are not required to set those fields and I'd prefer not to have to fill them with random invalid data just to get the API to commit my change.

[Spencer Zier]

Unfortunately, we don't currently have support for that.  Both the controller name and address must be specified.  That said, we do have an item on our backlog to bring more flexibility to this resource.

[timway001]

Side-note: If we want to file a bug / feature request do we go through TAC?

[Spencer Zier]

For bugs, yes, you can go through TAC (you can also report API bugs here, sometimes that can save you the hassle of dealing with TAC, and if there's no response here then proceed with TAC).  For feature requests for Prime Infrastructure, you have a couple options: you can email ask-prime-infrastructure@cisco.com or you can use the feedback tool built into the product (top right menu w/ gear icon > Feedback > I wish this page would...).  For API feature requests, you can make them here, and if you don't get a satisfying response, you can always use the previous two options

[timway001]

Update: I can also confirm you do not have to specify a controller at all. You send an empty string for the name and a value of "0.0.0.0" for the address like my example for setting only a primary controller.

So the take-away: A null value of 0.0.0.0 for the InetAddress is equivalent to an empty string and has to be specified that way.

[timway001]

I think I have found some positive middle ground. I am able to get a successful commit of the API by specifying a value of "0.0.0.0" for the address for any controller I do not want to set. So the JSON to set a single APs name, location (mapLocation) and Controller IP address is as follows:

The relevant values have been changed to protect the innocent:

PUT /webacs/api/v1/op/apService/accessPoint

{

  "accessPoint" : {

  "accessPointId" :  2,

  "adminStatus" :  true,

  "mapLocation" : "MyFirstBuilding",

  "name" : "MyFirstAp",

  "unifiedApInfo" : {

                    "primaryMwar" : "WLC1",

                    "primaryMwarAddress" : {

                        "address" : "10.2.2.41"

                    },

                    "secondaryMwar" : "",

                    "secondaryMwarAddress" : {

                        "address" : "0.0.0.0"

                    },

                    "tertiaryMwar" : "",

                    "tertiaryMwarAddress" : {

                        "address" : "0.0.0.0"

                    }

        }

    }

}

Edit: To include a post further below the takeaway is that the "address" field is of type AccessPointUnifiedDetails.InetAddress and to specify a null value like an empty string you can send "0.0.0.0" and you will get a successful commit. This includes setting an AP to not have any controllers specified. As a takeaway for other AP calls I'd venture it's safe to determine and then send the null or empty string value a particular type you want to leave unset.