WS Pagination Not Terminating

Hey Everyone!

We are working on a Web Services connector and I am having an issue with, what seems to be, pagination termination for account aggregation.

The WS connector calls the initial URL and receives 5000 records along with a new Paging URL in the body that needs to be called separately for subsequent records.

The initial fullUrl looks like this:
https://{baseURL}/Reports/{reportName}

Note: baseURL and reportName are not a true variables, they were just removed for the purposes of this post.

The response body returns data like this:

{
	"Data": {
		"XRefCode": "{reportName}",
		"Rows": [
			{
				"FirstName": "John",
				"LastName": "Smith",
				"EmployeeNumber": "0001",
				"PersonalEmail": "[email protected]"
			},
			{
				"FirstName": "Jane",
				"LastName": "Doe",
				"EmployeeNumber": "0002",
				"PersonalEmail": "[email protected]"
			}
			]
	},
	"Paging": {
		"Next": "https://{baseURL}/Reports/{reportName}?cursor=mn%252BRod94XqEEsF0rMrCTCrRzsdBTxAUt4mdlQMXxuC2NSmrjqRPGb0THtW9nGRon"
	}
}

The Paging Steps are:

TERMINATE_IF ($response.Paging.Next$ == NULL) || ($endpoint.fullUrl$ == NULL) || ($NO_RECORDS$ == TRUE)
$endpoint.fullUrl$ = $response.Paging.Next$

I started with just the first TERMINATE_IF condition and added the subsequent ones to attempt to fix this issue, but no luck.

The connector is able to parse the first 5,000 records, then the subsequent set of records on the second call (there are currently less than 10,000 records so only 2 calls needed at this time).

However, whenever an aggregation is complete, it shows it as an error with this message:

sailpoint.connector.ConnectorException: Url: , Message: 0 : org.apache.http.client.ClientProtocolException, HTTP Error Code: 0

Looking at the ccg logs, it looks like this is being caused because it is attempting to make another (third) call and the $url is empty, so this error is returned.

==> Dumping request for troubleshooting purposes: HttpRequestWrapper [url=, headers={Authorization=Basic ***, Accept=application/json, Content-Type=application/json}, payload=null, type=GET, allowedSuccessCodes=[0, 2], possibleHttpErrorCodes=, possibleHttpErrorMessages=]"

“Sending request to URL using headers [Authorization, Accept, Content-Type].”

NOTE: Double space in above message after “URL” because $url is empty

“Error while request handling: null, cause is: org.apache.http.ProtocolException: Target host is not specified”

When a call is made that does not have any Paging information, the body returns this for the Paging.Next value:

"Paging": {
		"Next": ""
}

So the final successful call that has data returns an empty value for Paging.Next. I know this is different from a true NULL value, but the paging documentation states that a conditional check for NULL indicates it will check for a null or empty object so I would expect paging to terminate upon seeing this empty value returned.

Any thoughts on how to successfully terminate paging in this case to prevent IDN attempting to call an empty url which causes the error message?

Thank you!

  • Zach

Have you tried

$response.Paging.Next$ == ""

Not sure it will work, but worth a try I guess

Thanks for the recommendation! I did try that at one point, but it was with the other termination conditions I have listed and it still wasn’t working. I figured I would try your suggestion as the only condition but unfortunately, it still results in the same error. Two successful calls then a third call with an empty $url.

Anybody have any additional thoughts on this? I have been working on some other potential solutions, but getting this working would still be the best option if possible.

If you get 5000 records per paging step, can you use

TERMINATE_IF $RECORDS_COUNT$ < 5000

Somewhat related - I use for Okta web service connector TERMINATE_IF $responseHeaders.link.next$ == NULL

That was working fine for a long time, but something recently broke in Web Services connector paging steps, and it no longer works as expected. So there might be more broken behind the scenes with pagination.

1 Like

The documentation with Okta as an example is what I actually used as a bit of a guide to get the new pagination URL. This was just slightly different since it was coming from the body instead of the header, but I was still expecting it to work pretty much the same. I noticed in some of my different tests that while I was always getting the empty $url error, the aggregation would get terminated mid processing. So if I ran one aggregation, I would get say 5,200 records. Then the next one without any pagination changes would have something like 5,580 and it would keep incrementing with each run until it finally had all of the accounts. I just figured I would address the extra call error first and see if that resolved all of the issues instead of adding that to my already lengthy initial post.

With that being said, your suggestion worked perfectly for us! I was really hoping I was missing some simple solution when I posted this issue and that, at least in part, seems to have been the case. It is unfortunate to hear there seems to be some buggy behavior going on with the pagination steps, but your suggestion TERMINATE_IF $RECORDS_COUNT$ < 5000 resolved all of the issues we were seeing. There is no extra call and the aggregation is fully processing each time.

Thank you very much for helping me get this resolved, it is greatly appreciated!

@colin_mckibben I just figured I would bring this thread to your attention for your awareness. It seems like Jason and I both have noticed some issues with the pagination steps according to how the documentation states they should work, particularly when trying to use NULL. Just wanted to mention it in case you have seen/heard of this issue elsewhere, but Jason was able to help me figure out a solution for this topic.

Thanks again Jason!

1 Like

This topic was automatically closed 60 days after the last reply. New replies are no longer allowed.