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.

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

Found the "IDM connector for Text Protocols (universal)"  at http://www.opns.be/idm-connector-for-text-protocols-universal/ According to the documentation is seems to be the REST driver that should be in the product.

Has anyone already worked with this driver?

regards,
Thomas

I suspect that the Rest driver came to existence from the Groupwise Driver (which came first), instead the other way around - which would have been the right way to do it.

And as Norbert mentioned there is an request to get access to the (returned) http hearders, now we're waiting.

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

Hi Abhishek,

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

Regards,
Casper

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!

Regards,
Abhishek

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.

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