CSCvg64354 - ISE ERS calls should be processed much faster - 2

[dhook]

Hello,

Seems not much is happening regarding enhancing the speed of the ISE API. It takes hours to first read all the id's, and then enumerate all of them when you have a fairly large deployment.

I have two suggestions that might be quite easy to implement without affecting the ERS design in any major way.

Suggestion 1. Add a new Global Operation that permits export of the endpoint database. ISE already has methods for creating a file, this would just make it accessible via the ERS API. Although this is not really a pretty "API", it would give us a quick way to get all the endpoints. It is easy to parse a csv file in code.
With "Global Operation" I mean the poorly documented operations available via the ERS documentation link. Not the one on DevNet, the one on the ISE server itself. There is already some export functions available here, like https://MyLabISE:9060/ers/config/op/globalexport/vcs/export.

Suggestion 2. The ISE id is using GUIDv1. This means that the GUID contains date and time. Not sure if this is an intentional design choice but I hope it is.
If you can add the "id" as a permitted filter either for sorting or reading (or preferably both), then it is possible to filter only new objects in an somewhat easy way. This enhancement will make it easy to get only new objects. It is already possible to filter on profileId and groupId, so why not add the Id as well?

For example, the GUID below has a timestamp of 2018-06-14 10:53:19.885000.0 UTC.

https://www.uuidtools.com/api/decode/266d03d0-6fc1-11e8-8511-123456123456

There is many libraries available the we can use in our code to utilize this. I would like to be able to query the ISE like this:

curl https://myLabISE:9060/ers/config/endpoint?filter=id.STARTSW.266 -u ersuser:erspass --header Accept:application/json -k
{
"ERSResponse" : {
"operation" : "GET-getAll-endpoint",
"messages" : [ {
"title" : "The filter field 'id' is not supported",
"type" : "ERROR",
"code" : "Query string validation exception"
} ],
"link" : {
"rel" : "related",
"href" : "https://myLabISE:9060/ers/config/endpoint?filter=id.STARTSW.266",
"type" : "application/xml"
}
}
}

Or like this:

curl https://myLabISE:9060/ers/config/endpoint?sortdsc=id -u ersuser:erspass --header Accept:application/json -k
{
  "ERSResponse" : {
    "operation" : "GET-getAll-endpoint",
    "messages" : [ {
      "title" : "Sort field 'id' is not supported. Only 'name,description' fields are supported.",
      "type" : "ERROR",
      "code" : "Query string validation exception"
    } ],
    "link" : {
      "rel" : "related",
      "href" : "https://myLabISE:9060/ers/config/endpoint?sortdsc=id",
      "type" : "application/xml"
    }
  }
}

I hope you take this matter seriously. An "API" that takes forever to read information is just disappointing. Reverting to web scraping etc when there is a better way (and you are so close) it not the way forward.

Kind Regards,

Dan