Webservice Connector

Team - I have a requirement to call relative API URL using Aggregation with Parent - Child Endpoints Configuration.

I have implemented the way its described in document below. But I need to pass the value which is multivalued(list) schema attribute to Child endpoints. I see connector taking one value but not all.

Aggregation 1 :
Parent API - Return - list of logins

Aggregation : 2 (this operation will return list of users response)

Child API - /url/site=$response.schema_att$ // its multi valued and not getting iterating to all values in child API aggregation operation.

https://community.sailpoint.com/t5/IdentityNow-Connectors/Web-Services-Source-JSON-Response-Examples/ta-p/74931

please suggest me if I need to change any of my configuration.

Thanks,
Suresh

1 Like

Hi @sureshkumar_v,

The following information will help us diagnose your issue.

  • Is schema_att a string or an array?
  • What does a sample JSON response from Aggregation 1 look like?
  • What does the child API URL look like normally? Is it /url/site={attribute} or /url/site=[attribute1,attribute2,...].

Hello @colin_mckibben

  1. schema_att is array ( we have configured as multi valued string in schema definition)

  2. JSON response from Aggregation 1
    [
    {
    “schema_att”: “site1”,
    “id”:1

    },
    {
    “schema_att”: “site2”,
    “id”:2

    },
    {
    “schema_att”: “site3”,
    “id”:3

    },
    {
    “schema_att”: “site4”,
    “id”:4

    }
    ]

  3. The child API URL should be like - /url/site={attribute}

Hmmm. This should be possible, but might be dependent on how you configured your parent and child account aggregations. Let me share an example of a similar scenario that I encountered and maybe it will help you spot any differences you might have in your configuration.

I am working on a web service connector for this very community forum, which runs on Discourse. I need to aggregate all SailPoint accounts in the forum so I can track and manage SailPoint employee’s access to this forum. The API for Discourse provides a list endpoint to get all accounts, and I can use this to get each account’s id, username, and title. However, this list endpoint doesn’t return the email address for each account. To get the email address, I have to call the get single user endpoint, which returns a lot more information about each user, including their email address.

To implement this in IdentityNow, I have to create two Account Aggregation operations. The parent aggregation will use the list endpoint to get all accounts and their basic attributes. It has the following configuration in the UI:




The response from the list endpoint looks like this:

[
    {
        "id": 10921,
        "username": "john.doe",
        "avatar_template": "https://avatars.discourse-cdn.com/v4/letter/s/b28a4f/{size}.png",
        "active": true,
        "admin": true,
        "moderator": false,
        "last_seen_at": "2021-08-31T13:41:46.161Z",
        "last_emailed_at": "2021-09-28T15:57:50.727Z",
        "created_at": "2021-08-17T14:16:07.856Z",
        "last_seen_age": 2520721.489948948,
        "last_emailed_age": 93356.923058227,
        "created_at_age": 3728259.794119657,
        "trust_level": 4,
        "manual_locked_trust_level": null,
        "flag_level": 0,
        "title": "Developer Relations Team",
        "time_read": 394,
        "staged": false,
        "days_visited": 6,
        "posts_read_count": 10,
        "topics_entered": 4,
        "post_count": 0,
        "akismet_state": null
    },
    ...
]

The child aggregation will use $response.id$ to call the single user endpoint for every account that was returned by the parent. It has the following configuration:




1 Like

Thank you @colin_mckibben for detailed explanation. I have configured the Parent and child exactly same way but I see child aggregation one time and I see one site users returning from Account aggregation task.

The one change I am having , child aggregation having response mapping field like below. Because child aggregation API attribute path similar to what we have in parent aggregation.

Can you send me screenshots of the parent and child aggregation configurations like I did? Also, can you send me a sample JSON response for the child aggregation?

Parent



Response from Parent Aggregation

[
{
“login”: “org1”,
“id”:1

},
{
“login”: “org2”,
“id”:2

},
{
“login”: “org3”,
“id”:3

},
{
“login”: “org4”,
“id”:4

}
]

Child Aggregation




Expected response from Child Aggregation (child aggregation will pull the users from each org which is return from parent aggregation)
[
{
“login”: “user1”,
“id”: 236,

},
{
“login”: “user2”,
“id”: 236,

},
{
“login”: “user3”,
“id”: 236,

}
]

The aggregation runs and fining one organization and members not looping through all organization.

In your account schema, what attribute is set as “Account ID” and what attribute is set as “Name”?

Everything looks in order… I’m not seeing what could cause this to only aggregate one account. I have a suspicion that the issue is orginating from the parent aggregation. Can you try deleting the parent aggregation and setting up one aggregation operation to aggregate a single org? For example, have one account aggregation with the context URL set to:

/api/v3/orgs/org1/members.

My theory is that if a single aggregation operation can aggregate the accounts for one org, then perhaps the issue is with the parent aggregation and iterating over all of the orgs.

I have tried that before with single org aggregation (without parent agg) and it was working and pull all users from given org.

Another test… What happens if you keep the parent aggregation but remove the child aggregation? Do you see an account created for each org, or just one account? If just one, what is the orgid and orglogin?

I did test that as well before … Here is the screen shot for parent aggregation without child.


The org created as uncorrelated accounts.

When I change the response mapping to orglogin(schema) = login(attribute path) & orgid(schema) = id(attribute path) , then users are deleting since Account ID and Name mapped to login.

I’m fairly certain the root of the issue is that your parent aggregation isn’t aggregating accounts, but getting a list of orgs that the accounts exist in. Typically, the parent aggregation will get a list of accounts, and the child aggregation will use those account IDs to get more attributes for each account from different endpoints. Your case is the reverse, where you are getting specific attributes of an account (the org the account exists in), and using those to then get all of the accounts.

Is the orgid and orglogin important for your account schema, or do you only need those attributes to paginate through all of the orgs to get the accounts? Also, how many orgs do you have? If it’s a small number, like 4, and you don’t anticipate it growing very often, then you could try creating 4 account aggregation operations that aren’t linked to each other. Each operation will use a different org in the context URL so you capture all accounts in every org.

Account Aggregation - Restricted
contextURL = /api/v3/orgs/restricted/members

Account Aggregation - Secure
contextURL = /api/v3/orgs/secure/members

etc.

Thank you @colin_mckibben

The actual requirement is pull users from all orgs( orgs will be added). Also I have few more subsequent calls to make from org similar to users.
I have tried the options that you suggested( like static) way, its working but we wanted to know we can go with OOTB connector config.

Do you think we can call out this behavior is not viable option through OOTB configuration ( without rules) ? . please share your thoughts.

I have my next option to try with connector rule ( import through connector-rule API), I assume that it will be more level of effort than configuring the apps in UI.

Thanks,
Suresh

I talked with an internal expert, and he verified that the order of API calls that you need to make to aggregate accounts can’t be done solely through the UI. You will need to create a before operation and after operation rule to handle this. Our expert gave me a lot of information on how this could be accomplished through rules, so I’d be happy to work with you via direct messages to get this working in your environment. Once we have a solution that works, we can post that solution back in this thread as the answer.

hi @colin_mckibben - we’re facing a similar issue trying to perform github onboarding (although via IIQ 8.2) . Here is a summary of steps we have taken -
a) get a list of organizations in Github (URL - /organizations). This returns values like -

[
{
“login”: “Org1”,
“id”: 245
},
{
“login”: “Org2”,
“id”: 424
}
]
b) Get the org login to find all the related teams – not working
URL- /orgs/$response.login$/teams
This should return this org teams value like -

[
{
“name”: “Team1”,
“id”: 123,
“description”: null
},
{
“name”: “Team2”,
“id”: 456,
“description”: null
}
]

Few issues we have noticed are -
a) the 2nd call seems to return only one team for only one org (that org had only 1 team) and doesn’t pull another teams belonging to other orgs
b) we constantly see identity attribute was not found in the error logs. We have tried amending the group schema/response to solve this but still remains unsolved.
c) we have noticed a massive caching problem with this app(and other apps) i.e. if we add a before rule or after rule and try a group aggregation it doesn’t get picked up - is this a known IIQ 8.2 issue

Any advise would be helpful here

Hi Aditya,

It looks like you’re asking about an IIQ feature. To help keep our categories organized an on topic, can you please ask your question in the IIQ category?

yep created Github onboarding using Webservices connector

1 Like

Hi Colin, can you also share the information with me either through direct messages or here. I am also encountering a similar problem and that would really help.