REST Driver and Pagination (Link Header with rel="next")


I´m working on an IDM integration of an existing REST API using IDM 4.8.1 and  the REST driver The driver has to provide user and group entitlements with value from the application.

The API has an endpoint to get the list of available permissiongroups, but as result of a GET request the API returns only a limited number (currently 100) of objects plus a Link header with rel="next" to get the next.

Level 7 Trace shows the returned header (with anonymized URLs):

[09/15/20 14:27:48.668]:RESTDRIVER PT:RESTDRIVER: poll
[09/15/20 14:27:48.669]:RESTDRIVER PT:RESTDRIVER: Custom: preparing GET to apiserver.domain/.../permissiongroups
[09/15/20 14:27:48.670]:RESTDRIVER PT:RESTDRIVER: Resetting headers
[09/15/20 14:27:48.670]:RESTDRIVER PT:RESTDRIVER: Setting the following HTTP request properties:
Authorization: <content suppressed>
[09/15/20 14:27:48.670]:RESTDRIVER PT:RESTDRIVER: Accept:application/json
[09/15/20 14:27:48.671]:RESTDRIVER PT:RESTDRIVER: Did a HTTP GET with 0 bytes of data to apiserver.domain/.../permissiongroups
[09/15/20 14:27:48.671]:RESTDRIVER PT:RESTDRIVER: *******************************************************
[09/15/20 14:27:48.672]:RESTDRIVER PT:RESTDRIVER: **********************LOGGING REQUEST******************
[09/15/20 14:27:48.672]:RESTDRIVER PT:RESTDRIVER: *******************************************************
[09/15/20 14:27:48.672]:RESTDRIVER PT:RESTDRIVER: Request URL :apiserver.domain/.../permissiongroups
[09/15/20 14:27:48.673]:RESTDRIVER PT:RESTDRIVER: Http Method : GET
[09/15/20 14:27:48.673]:RESTDRIVER PT:RESTDRIVER: Sending http request with below headers :-
[09/15/20 14:27:48.673]:RESTDRIVER PT:RESTDRIVER: Authorization: <content suppressed>
[09/15/20 14:27:48.673]:RESTDRIVER PT:RESTDRIVER: Accept: application/json
[09/15/20 14:27:48.673]:RESTDRIVER PT:RESTDRIVER: ***************************END**************************
[09/15/20 14:27:48.943]:RESTDRIVER PT:RESTDRIVER: ********************************************************
[09/15/20 14:27:48.943]:RESTDRIVER PT:RESTDRIVER: ***********************LOGGING RESPONSE*****************
[09/15/20 14:27:48.943]:RESTDRIVER PT:RESTDRIVER: ********************************************************
[09/15/20 14:27:48.943]:RESTDRIVER PT:RESTDRIVER: Http response code : 200
[09/15/20 14:27:48.943]:RESTDRIVER PT:RESTDRIVER: Http response status : HTTP/1.1 200 OK
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Getting http response with below headers :-
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Date: Tue, 15 Sep 2020 12:27:40 GMT
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Server: Apache
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Expires: 0
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Cache-Control: no-cache, no-store, must-revalidate
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Pragma: no-cache
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Content-Length: 11508
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Link: <apiserver.domain/.../permissiongroups rel="next"
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Keep-Alive: timeout=3, max=10000
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Connection: Keep-Alive
[09/15/20 14:27:48.944]:RESTDRIVER PT:RESTDRIVER: Content-Type: application/json
[09/15/20 14:27:48.945]:RESTDRIVER PT:RESTDRIVER: Sending http response with body :-
[09/15/20 14:27:48.945]:RESTDRIVER PT:RESTDRIVER: {"liste":[{..... <the first 100 records> }]}

The API does not allow to force a complete result set, or a required number of results in the request, so I have to follow the Link.

I could not find any information on how to get the REST driver to follow the links to get the complete data.

Would be grateful for any ideas...

best regards,

PS: This is also an issue from publisher poll request.



Parents Reply Children
  • Hi Abhishek,

    Will you document how this is done (in details) ?


  • Hi Casper,

    With the enhancement in place with a forthcoming release, there wouldn't be a need for this less than optimum mechanism to be documented.

    Let me see what can be done in the short term. Additionally, we already have experts on the community(including you!) who I hope would offer guidance!


  • I think what Casper is asking you, is how to handle the pagination in a document modifier?

    I think he is referring to your first sentence "Norbert’s SR should allow handling pagination (albeit painfully) through Document Modifiers in the short term."

    Not the second one.

  •   abs.  the pagination functionality is must-have  built in netiq REST driver, i would vote for this for sure, mostly REST api today if done (professionally) does pagination, example Microsoft Graph and other oDATA apis, so yes, it would be still possible to do work-around with current version,  but NetIQ REST driver should be smart enough to discover REST api and support pagination out of the box. 

    one of the work around could be:


    1) Issue query from subscriber command transformation

    2) Output transformation should implement command 

    3) Publisher input return data from REST api , as result set with pagination back to subscriber command

    4) Subscriber command transformation recieves result set, parse data, and  submit new command with new pagination link


    this would work, if the response of first query is not so big enough, so smart idea would be to issue query with filters possible to reduce the result-set received from service.


    but yes, it requires some experience and knowledge of netiq.











  • Different REST Systems handles pagination in different ways. But the way the pagination is handled is often returned in the response header returned by the system. Currently the driver does not provide a way to access the response header.

    We will implement this shortly where the headers returned in response will also be part of the response like <response-headers> as part of <driver-operation-data>. This will give the access (for example link in this connected system) in the policy channel and pagination could be achieved by writing policies based on the <response-headers>

  • There is probably another problem with that even if the response header will be available in the policies soon.

    The codemap refresh results are only available in the input policies, so the query for the additional bunches of results will have to be done from there, but a query from an itp policy back to the application does not flow through the otp policies. Therefore no conversion from XDS to JSON an so on is done and the shim does nothing. 

    Do i miss something?

    best regards,

  • The Code-Map refresh supports query-ex, so it should be possible to use the "Link https://...." if you could get your hands on it.

    I do not know how to do query-ex with the code-map refresh, just know that it's supported.


  • Thank you, query-ex is a good idea!

     I´ve tested with an entitlement marked as query-ex supported. 

    The codemap refresh then injects a query-ex token, but it does not make any difference for the current REST driver 1.1.1 --> the query result looks like from a normal query

    The REST driver documentation 1.1.1 also does not contain any information about query-ex so it probably does not support query-ex currently (besides the header part).


  • SO when you have issues with CMR, like timeouts, takes too long, runs too often, what I suggest is in the ITP catch the query for CMR.  Then change it to something you know will return and fast. I like the __driver_identitication_query__ since all drivers have to support it, handled in the shim, no network/connection traffic.

    Then tag it with op-data so you can catch the __driver_identification_response__ in the OTP.  Then clone in your values to the <instance> document.

    There was a recent thread where someone had CMR fail since it did not finish inside a hard coded 10 min window so it kept running.  David Gersic and I discussed a solution he worked on (we are colleagues) where he used a Job to do the CMR's data collection task on a better controlled schedule, and then simply stored the <instance> XML in a text blob on an object. Then when catching the CMR query response in the OTP, clone the contents of that object into the results, and it is fast and controlled.

    Similarly here, you could likely create a Job and catch the <trigger> event in the Sub-ETP so ITP applies to the queries, do the work, store it somewhere, and then when CMR happens and you catch it in the OTP, replace the results with the pre-collected data.


    Agreed, would be nice if it worked as it should, but you can work around it if it does not.

  • I though so, somehow you need to return the token (Link) to UA which then should use that for the next query - complicated. And as long as you can't get your hand on the return header values, there is no way to make this work.