Currently the REST driver returns the request headers with the response instead the ones send by the server. (I opened an SR for this). So to get the value for Link respose header, you'll probably have to look at writing a DocumentModifier: https://www.netiq.com/documentation/identity-manager-48-drivers/generic_rest/data/bvpan6k.html

While this seems like a daunting task, it turns out, with basic Java skills you can do this.

What happens is there is a skelton file in the Driver Dev kit, with the various classes you can add to the SOAP or Delim text drivers.

They are basically a class definition that takes the document as input, and then returns your modified version. (For the most part).  So your code goes inside and does what is needed.  Now offhand, I have no idea how to get access to the headers... Nor how to write to them, but seems doable.

You mean the "Document Handling" class stuff?

I am not sure that  it will be possible to get the http headers after the XDS document is recreated and send to your custom document handler.

Thank you for your answeres.

Currently I understand:

- the REST drriver shim itself does NOT handle paged results (thats what i initially expected)

- the Link header from the response is not passed to the event ans is therfore not available in policies

- it is not sure, if a Java extension can get to the Link header

So it looks like the REST driver possibly is not the way to go...

I could look into writing my complete own driver shim or look into the new Invoke REST Endpoint action (whitch lacks the PATCH method at least according to the documentation).

Any other ideas?

best regards,
Thomas

Thomas, Norbert’s SR should allow handling pagination (albeit painfully) through Document Modifiers in the short term.

As for supporting pagination natively, I would recommend that you log an ideas exchange request. We are actively looking at enhancing the capabilities of the REST driver, and this should get addressed with the next release of the driver.

Regards,
Abhishek

  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.

Regards

/Maqsood

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,
Thomas

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.

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.

Hi!

This is how I solved it:

I intercept the permissiongroup entitlement query in an OTP and covert it into a query for class "__driver_identification_class__" like the account entitlement query does and as Geoffry suggested.

In an ITP policy before NETQRESTJSON-itp-JSONtoXDS I use a custom Java class based on Apache HTTP client to query the values from the rest service in a "while Link header is set" loop without using the REST driver´s shim.

The results are converting into a REST driver compatibel JSON format using ECMA code and injected into the <status> element so that it looks like the "normal" response oft the REST driver´s shim:

<nds dtdversion="3.0">
<source>
<product build="20200821_0139" version="1.1.1.0">Identity Manager REST Driver</product>
<contact>NetIQ Corporation.</contact>
</source>
<output>
<status event-id="0" level="success" type="driver-general">
<driver-operation-data class-name="permissiongroup" command="query" event-id="0">
<response>
<header content-type="application/json"/>
<value message="OK" status="200">{"totalResults":456,"results":[{...}]
</value>
</response>
</status>

The existing rules in NETQRESTJSON-itp-JSONtoXDS then convert the JSON query response to a list of instances.

That is what codemap refresh needs.

The downside is that I have this custom Java code and two ways of talking to the REST API.

Thank you for all your suggestions
Thomas

A pretty cool solution, I must say.

Just shows that we need a pure http client driver from MF, just a simple driver which can do transport. I know about Steffan's driver, but MF over engineered their REST driver...