REST driver pagination any news?

Hi,

I have read a couple of discussion on here from 4 years ago with some cleaver workarounds for pagination on REST drivers.

I have looked at the documentation for 4.8 and found this section

And this seems like an easy setup:

But when I go to set it up i only have "text fields" in the configuration page..

Have any of you had any luck setting up pagination via this configuration?

Parents
  • 0  

    You need to enable Pagination. What version of IDM is this - you might need to use 4.8.6 or later to get the option (I did not see it with 4.8.5, but 4.8,7 does show it).

    And please, do report back on how it works.

  • 0 in reply to   

    Have anyone made this work?

    I have a response like this : 

    {
    "@odata.context": "">connector.mindkey.com/.../$metadata
    "@odata.count": 3026,
    "value": [
    {
    .......
    }
    ],
    "@odata.nextLink": "">connector.mindkey.com/.../PositionVersion
    }

    I have set the driver to 

    When does the next page "happen"?

    I call the endpoint - then i read the data by grabbing xpath(.) and using javascript i extract my data.

    Then i work on the data and in this case add my employees and then i do strip xpath (.) 

    Otherwise i get something like "error because of opperation data in input element"

    Then my driver kinda stops..

    So when are the Driver calling the next page? have i stripped the next page information? Can i add it with xpath somehow?

  • 0   in reply to 

    I THINK the shim is expecting your JSON->XML to spit out an <instance> doc and probably with a <query-token> node specifying the next node.  SO in your case, @odata.nextLink in some format. 

  • 0   in reply to   
    THINK the shim is expecting your JSON->XML to spit out an <instance> doc and probably with a <query-token> node specifying the next node

    Polling functionality is all self-contained within the shim from what I understand.

    The JSON->XML translation always happens on the engine side, not in the shim.

    What is confusing, is that like the AD driver, the default engine side policies call out to a java class that is normally bundled with driver shim updates. When per best practice, one runs the driver shim on a separate remote loader, it is far too easy to forget to update/patch/install this java class on the engine side, which can cause engine side policy evaluation to fail.

    Now don't get me started on how broken and poorly written the built-in JSON->XML implementation that ships with the REST driver is. One of the first things I do when working on a REST driver is to replace this with a less broken and more flexible approach (several options exist).

Reply
  • 0   in reply to   
    THINK the shim is expecting your JSON->XML to spit out an <instance> doc and probably with a <query-token> node specifying the next node

    Polling functionality is all self-contained within the shim from what I understand.

    The JSON->XML translation always happens on the engine side, not in the shim.

    What is confusing, is that like the AD driver, the default engine side policies call out to a java class that is normally bundled with driver shim updates. When per best practice, one runs the driver shim on a separate remote loader, it is far too easy to forget to update/patch/install this java class on the engine side, which can cause engine side policy evaluation to fail.

    Now don't get me started on how broken and poorly written the built-in JSON->XML implementation that ships with the REST driver is. One of the first things I do when working on a REST driver is to replace this with a less broken and more flexible approach (several options exist).

Children
No Data