Generic REST Collector supporting odata

I am considering to connect an application offering an odata compliant REST API to IG (3.7.3), and I am wondering if it is possible - and/or suggested - to modify the shippir REST collector for GiHub.

Unfortunately, without modification the REST GitHub Collectors cannot be used for this challenge, since they have some "hard" coded stuff in them.

After exporting the collector I found only the following two functions:

  • getRestResource(connectionParm, token, pageSize)
  • getNextPageURL(response) 

I believe, the responsibility of the first one is to implement the REST request and compose the JSON object representing the collection.

The code seams to utilize a paged search (token = '/users?per_page=' + pageSize;) which can not work for two reasons when working with odata:

1) the schema (/users) is not correct

2) odata does not support paged searches in this way.

The schema can be possibly simply set to the one used in the odata implementation, but the paged search has to be implemented differently.

 In addition to these findings, the first function uses some "HelpperFunctions" provided by com.netiq.daas.restconnector.internal.HelperFunctions!

Can anybody provide some information regarding the HelperFunctions class, and the structure of the final JSON object, IG is able to process?

In case a paged search can not be implemented for odata, is there a technical limitation on the data received in one REST response?

To replace a paged search odata offers the parameters &size and $skip - so a paged search could be replaced by a loop running several requests with in increasing value in the $skip parameter, if needed!

I am not sure, regarding the purpose of the function getNextPageURL(response)  - is this needed, or does this need to be adapted as well?

Kind regards

Thorsten

Parents Reply Children
  • Hi Norbert,

    I will forward this information to my customer - but since I did some progress in my lab, I will spend some more time on further tweaking the function contained in the GitHub Collector.

    So far, I am able to read all meaningful account data in one request. The next stage will be to implement a kind of paged search in case there are hundreds or thousands pf accounts to be imported ;-)

    Kind regards

    Thorsten