We have a requirement to do single account aggregation for a webservices connected source, but the API does not support filtering, so just wanted to know if it is possible to use $getObject.nativeIdentity$ in Root Path / Response Mapping to filter out? If yes, please provide inputs on how to use it,
We can use $response only when we have a parent endpoint right?
I was trying to add a filter as such in Root Path as below, but it did not work
$.Report [?(@.ID == “$getobject.nativeIdentity$”)] , i need nativeIdentity without which i wont be able to filter out the response for single account aggregation.
I have seen this document, this is not helpful for single account aggregation.
Using filters i cannot dynamically populate value via the filter to do single account aggregation.
The feature which i want to use is Loading Account Data - SailPoint Identity Services
Hello @supi890
Do you mind sharing more info like:
Name of the WSC Source
Context of your requirement
If the WSC Source does not support fetching single account details, then there is nothing much you can do. However, based on your specific requirement, you might be able to combine multiple options available in IDN to achieve what you want to
Requirement: The API response contains all records (there is no filtering option) so i wanted to know if there is any way to use $getobject.nativeIdentity$ in the response root path/ response mapping so i can provide single account aggregation feature. The reason i am looking for this option is client wants to handle immediate termination via Support team but is only providing helpdesk access to support team, this way they cannot change lifecycle state manually. So only alternative is to allow single account aggregation, support team can initiate “Single Account Aggregation” to fetch latest details, based on the details lcs can be recalculated.
Okay… so you are planning to use $getObject.nativeIdentity$ as a filter parameter in response root path (Something like $.[?(@userId=\"$getObject.nativeIdentity$\")]). This might be a possibility, but again you are going to fetch all the records to filter out one single record? Does not seem like a good design approach to me. And, even if you wish to go this route, your approach will depend on certain factors like
does your source return all records in single call?
Or are you using pagination?
If you share the name of your WSC source, may be you will find someone who had a similar situation in the past and can help you better
The API returns all records in a single call and there is no pagination.
The reason i am not sharing WSC source name is because the application is home grown (client developed), they have exposed API recently.
If it’s a custom developed system, then there is no point sharing the name . On the same note, if it is custom developed, then they can easily create an end point to GET a single record (It is a part of REST API Guidelines after all)
Not having to paginate eliminates some complexity of your situation… Let me know if you were able to resolve the issue using the filter in root path