Single account aggregation | how to track the response id

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

Hi Team,

How to track the task id that comes as a response from API :submit-reload-account | SailPoint Developer Community

Regards

2

Hello @vbdm

Using the following API you can get the status of the task:
https://sailpoint.api.identitynow.com/beta/task-status/:id
For more information refer :

3

I don’t think so, or atleast I am not seeing that:

Here is an async job id as a response to reloading an account

image
image1243×402 26.9 KB

When I try to get the status of this async reload job using the get-task-status API, I get a 404 everytime, for every account, on any source.

image
image1181×366 24.6 KB

What am I missing?

Thanks

4

Are you sure you are you are using beta version but not other ?

5

Yes, I am using beta for both the calls. reload and get-task-status

6

Just tested it with 2024 adding experimental header and the same result

7

You are right , I tried it from my end . I believe the API is broken . Please raise a ticket. @colin_mckibben can you confirm this ?

8

Support will be able to reproduce and confirm if this is an issue.

1 Like
9

I initially faced this a few months back and came back to it today again.

if its broken, it must have been since few months

The use case mentioned on this post:

#1 is the test for which I need details of this response to map it to the account id.

Thank you

10

Here is a solution to track the Async job status

For a connector(atleast Okta), when Debug mode is enabled in the UI Administrator settings

When we use the CLI tool to output logs while we execute the reload-account commands, we see log lines like the ones below:

[2025-04-11T01:00:01.626-04:00] DEBUG | connectorMessage ▶︎ {"@timestamp":"2025-04-11T05:00:01.618Z","logger":"openconnector.connector.okta.OktaConnector","message":"Executing request GET https://{baseURL}/users/<native identity value> HTTP/1.1","thread_name":"pool-2-thread-12"}
[2025-04-11T01:00:01.720-04:00] DEBUG | connectorMessage ▶︎ {"@timestamp":"2025-04-11T05:00:01.712Z","logger":"openconnector.connector.okta.OktaConnector","message":"Response is received from Okta. Status: 200","thread_name":"pool-2-thread-12"}
[2025-04-11T01:00:01.720-04:00] DEBUG | connectorMessage ▶︎ {"@timestamp":"2025-04-11T05:00:01.712Z","logger":"openconnector.connector.okta.OktaConnector","message":"Retry coming from setResponseBody false","thread_name":"pool-2-thread-12"}
[2025-04-11T01:00:01.720-04:00] DEBUG | connectorMessage ▶︎ {"@timestamp":"2025-04-11T05:00:01.712Z","logger":"openconnector.connector.okta.OktaConnector","message":"x-rate-limit-limit 1250 x-rate-limit-remaining 1247 x-rate-limit-reset 1744347659","thread_name":"pool-2-thread-12"}
[2025-04-11T01:00:01.720-04:00] DEBUG | connectorMessage ▶︎ {"@timestamp":"2025-04-11T05:00:01.712Z","logger":"openconnector.connector.okta.OktaConnector","message":"Completed fetchHttpResponse ","thread_name":"pool-2-thread-12"}
[2025-04-11T01:00:01.721-04:00] DEBUG | connectorMessage ▶︎ {"@timestamp":"2025-04-11T05:00:01.712Z","logger":"openconnector.connector.okta.OktaConnector","message":"Account Read {\"id\":\"<native identity value>\",\"status\":\"ACTIVE\",\"created\":\"<created date>\",\"activated\":\"2020-01-27T16:18:40.000Z\",\"statusChanged\":\"2020-01-27T16:18:40.000Z\",\"lastLogin\":null,\"lastUpdated\":\"2025-01-25T22:18:05.000Z\",\"passwordChanged\":\"2023-01-05T02:40:04.000Z\",\"realmId\":\"<realmid>\",\"type\":{\"id\":\"<native identity value>\"},\"profile\":{***********}

These indicate the end point that the connector is using to fetch the account.
The last line also indicates that the account is brought back, which I have used as an indication that the async job is complete.

My interest is to measure the performance of a bulk of these single-account-aggregations at different times.

As expected, on my tenant, running through a loop of 100 accounts and getting the async-task-id usually takes 15 seconds, while the time it takes to complete all these jobs varies at different times during the day.

My complete design of the test framework:

Design: To measure performance of 100 single-account-aggregations

		0. Preparation: Run script 1: getNativeIds.py
				derive the 100 native ids from the account ids in test

		1. Reload Accounts: Run script 2: singleAccAggregations.py
				perform reload-account for these 100 accounts. Redirect the CLI logs to a log file. Make sure to collect logs for more duration than the usual execution of singleAccAggregations.py
				it gives time for all the account aggregations to come back and get logged
				
		2. Filter Account Aggregation: Run script 3: searchLogToCalculateTotalTime.py

				Note: Cli tends to push logs from the history as well. So, clean up the logs manually to start from the test time. This ensures correct total time & validation
				In the logs search  for a line line for each of the 100 native ids
					match for lines containing "message":"Account Read {"id":"<native identity value}",
					note the total time surrounding all the messages
					 
		3. Results: Part of Script 3
				output total time from script 2
				output all the matched log lines into another file:
					
		4. validation: Run Script 4: getMissingNativeIds.py
				Run a script to validate if all the natve ids noted in step-1 are present in the output file in step-4