I am contacting you all regarding an issue concerning account aggregation. I am currently in the process of integrating SailPoint with Confluence On-premises using the Web Service Connector.
There are no direct APIs available to retrieve the accounts from the application. I am attempting to implement multiple endpoints with parent and child endpoint relationships.
I would like to inquire if this is the correct approach or if there are any other alternatives for addressing this issue?
The restapi structure of the application consists of three distinct endpoints. The first endpoint is responsible for retrieving all the groups, while the second endpoint fetches the members of a specific group based on the group name. Lastly, the third endpoint allows for obtaining the user details by utilizing the userkey obtained from the previous endpoint.
Hi Ramireddy,
You can create as many parent to child endpoints for account or group aggregation as you want if a single API endpoint is not sufficient to aggregate all the data you require for that application just make sure the correct response attribute is passed from parent to child attribute for that hierarchy to work successfully.
This will create your connector more complex and also will have really bad performance . rather i would say that have a custom end point created which will give data in required format and then use that custom end point for integration .
Hi Jarin, We do have an out-of-the-box connector for integrating SailPoint and Atlassian Cloud. However, it is important to note that this integration is distinct from the one you mentioned.
Yes Deepanshu, I require further understanding of the web service connector, including its before and after operation rules, in order to address this issue effectively. I will try with additional efforts on this.
Hello Vishal,Unfortunately, the application team lacks extensive understanding of their APIs, which complicates the process of creating a distinct endpoint for this integration.
Hi Rami, I’m not sure, but I don’t think this approach will work.
As far as I know, you can’t do 2nd Aggregation without identifying the native Identity in the 1st one.
From my POV the best course is to have before operation rule consuming the APIs related to get the users from all the groups, then return it to them in the updatedmap.
This has some cons like Vishal said it will be complex and may have some performance issues, otherwise, you can use the OOTB connector (which I think it’s billable) or build your own custom connector (if you can/want).