SailPoint ISC Webservices SaaS connector account aggregation returning 0 accounts | TechnologyOne (CiA) API

Identity Security Cloud (ISC) ISC Discussion and Questions
, , ,
1

Hi All,

I am currently configuring a SaaS Direct Connect Web Services connector in SailPoint Identity Security Cloud to aggregate accounts from SaaS TechnologyOne (CiA).

I am running into issues getting the aggregation never run successfully and throws error .

image
image406Ă—162 3.63 KB

Depending on the script I use, I either get 0 records returned or the aggregation times out (suggesting an infinite loop).

I have confirmed via Postman that the API credentials and the endpoint itself are working correctly. The issue seems to be isolated to how the SailPoint paging engine is evaluating the termination condition.

API Details:

  • Endpoint: …/Api/WS/v2/User/List?page=X&pageSize=Y

  • Paging Type: Page-based (1-based index).

  • Expected Response Structure: A JSON object containing an array named DataSet.

My Current Configuration:

1. General Information & Context URL:

  • Context URL: /Api/WS/v2/User/List

  • HTTP Method: GET

2. Response Information:

  • Root Path: $.DataSet (Confirmed case-sensitive).

3. Account Schema & Response Mapping:

I have mapped UserId from the JSON to my id attribute, which is flagged as the Account ID.

image
image580Ă—291 3.93 KB

4. Postman Example Response:

Here is the JSON structure I am successfully getting outside of SailPoint:

image
image534Ă—544 21.6 KB

5. Paging Configuration (Current State):

Based on the official SailPoint documentation for limit/offset (page-based) paging, I am using the proprietary variables ($limit$, $offset$, $RECORDS_COUNT$).

  • Initial Page Offset: 1

  • Page Size: 50

  • Paging Steps:

image
image645Ă—367 4.63 KB

The Problem:

Even though this configuration appears to match the documentation examples :

If my test environment has fewer than 50 users (a partial first page), the $RECORDS_COUNT$ < $limit$ check seems to cause the aggregation to return 0 records.

I have also experienced timeout errors (possible infinite loops) when attempting to use other termination logic, such as checking for .length == 0 on the DataSet array.

Questions for the Community:

Has anyone successfully configured paging for the TechnologyOne CiA User/List endpoint using the SaaS Web Services connector?

Is there a quirk with how $RECORDS_COUNT$ is evaluated in the cloud engine when the very first page is not full?

Should I be using a different termination strategy for TechnologyOne, such as checking if the first element of the array exists (e.g., TERMINATE_IF $response.DataSet[0]$ == null)?

Any recommendations or examples of working paging scripts for this specific target system would be greatly appreciated.

Thank you!

2

Hi @yasha

It looks like since your first call is hitting the terminate call before it returns any records, I would try replacing that specific check with something like this:

TERMINATE_IF ($offset$ != 1) && ($RECORDS_COUNT$ < $limit$)

Let me know if this works for you!

3

Unfortunately, no luck.

image
image952Ă—737 31.6 KB

image
image1228Ă—393 22.8 KB

4

Thanks for trying it.

If you remove paging, does it aggregate all the users just fine (Just the ones on the first page)?

5

@trettkowski
Still no luck

image
image1001Ă—754 36.7 KB

image
image1219Ă—360 18.4 KB

6

Ah! Well that narrows down the issue.

That error typically indicates a VA issue, not anything wrong with your configuration. Have you tried restarting your VA?

Edit: Just realized this is a SaaS based connector, you can disregard the above.

7

I used a pageNumber system to fixed my pagination problems:


TERMINATE_IF $response.hasNextPage$ == false 

$endpoint.fullUrl$ = $application.baseUrl$ + “/name?pageNumber=” +($response.pageNumber$ + 1)+“&pageSize=1000”

Also, have you defined a starting point for $limit? I couldn’t see one

8

Don’t you need to mention the page=X&pageSize=Y in the first call?

9

I don’t think Pagination is his issue here or he’s at least not even getting to the pagination portion of his code hence why removing it did nothing.

I don’t think your pagination code will work considering his response from the API doesn’t have a hasNextPage response.

1 Like
10

@trettkowski
I took too long with my reply and missed the rest the conversation>
He did mention he was using a SaaS connector so no need for a VA.

@yasha Can you share your GET all connector settings

11

@iamnithesh
Thank you. I tried the recommended steps however still the aggregation failed with error and returning 0 accounts.

image
image1246Ă—541 28.1 KB

image
image1228Ă—634 42.5 KB

12

@phil_awlings

I currently only have two HTTP operations configured.

One for test and one for aggregation.

Sharing both for the reference and the current configuration

image
image1226Ă—469 25.2 KB

image
image1220Ă—453 25.3 KB

image
image1225Ă—412 19.8 KB

image
image879Ă—208 9.08 KB

image
image549Ă—541 23.4 KB

13

Have you tried with $RECORDS_COUNT$ < 50

14

Can you match the Account aggregation settings to same as functioning Postman example:
/List?page=184&pageSize=1

Then run an aggregation, and post the results. If that errors, then we know there is something wrong in the HTTP operation build

15

HI All,
I checked with SailPoint. It seems there were a lot of aggregation activities that got queued due to my previous aggregation attempts, and hence the all the current SaaS aggregation activity was failing for all the SaaS sources.
After waiting for those aggregation activities to complete the aggregation is happening ,however for the page Size setup ,the pagination code to aggregate accounts is not working. The aggregation HTTP operation always return number of accounts mentioned in the page size.

image
image993Ă—352 18.2 KB

Regards,
Yash

16

Good to hear you got past that issue. Try this for pagination! It’s close to the original you had, but it hard codes the limit so we can be sure that’s not the issue.

$limit$ = 50
TERMINATE_IF $RECORDS_COUNT$ < $limit$
$offset$ = $offset$ + 1
$endpoint.fullUrl$ = $application.baseUrl$ + "/Api/WS/v2/User/List?page=" + $offset$ + "&pageSize=" + $limit$
17

This also returned only first 50 accounts

18

Alright, last idea here. I see in the documentation it mentions relativeUrl instead of baseUrl even though I’ve seen baseUrl work in my own integrations.

Try this:

$limit$ = 50
TERMINATE_IF $RECORDS_COUNT$ < $limit$
$offset$ = $offset$ + 1
$endpoint.fullUrl$ = $application.relativeURL$ + "/Api/WS/v2/User/List?page=" + $offset$ + "&pageSize=" + $limit$

If you’re curious where in the documentation I’m seeing this, go here under paging keywords:

19

in your https ops –> general information –> context url try below :

/Api/WS/v2/User/List?page=$offset$&pageSize=$limit$

Have below in the paging steps

TERMINATE_IF $RECORDS_COUNT$ == $response.TotalRecordCount$
$offset$ = $offset$ + 1
$endpoint.fullUrl$ = $application.baseUrl$ + “/Api/WS/v2/User/List?page=” + $offset$ + “&pageSize=” + $limit$

for testing, configure you pages as offset : 0 and limit : 10 and on you aggregation , set delete account to 100% (don’t forget to change it back to whatever you want after testing)

20

I was about to ask where have you defined the variable $RECORDS_COUNTS$
But Chelsea has covered it in the above