Aggregating Accounts using Multiple (filtered) API Calls to a Single Endpoint

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

I’ve only done a few integrations using web services and have run into a situation that I haven’t been able to find a solution to. I saw one similar post here, but it was closed with no solution. All the other posts about multiple endpoints seem to be about getting the base list of users from one endpoint, then using a child one to gather additional attributes.

In my case, the /employees endpoint provided must be called with a filter, meaning there is no way to return all users in the first call. I’ve confirmed this API limitation with the company.

Here are the methods Ive tried. (in dropdowns for clarity)

Method # 1

  • Account Aggregation - 1 - Locations

    • GET /locations/
    • Root Path $.records[*]
      • JSON records array contains 90 location objects.
    • Response Mapping locationId -> locationId
      • locationId is in the account schema.

  • Account Aggregation - 2 - People

    • GET /employees?locationId=$response.locationId$
    • Root Path $.records[*]
      • The employees are always returned in an array, even if there is only one at that location.
    • Response Mapping employeeExternalId -> employeeExternalId etc.
      • There are 16 JSON attributes mapped to the account schema. They are named in ISC the same way they are named in the JSON objects for simplicity.
    • Parent Endpoint Account Aggregation - 1 - Locations
Method # 2

  • Account Aggregation - 1 - Locations

    • GET /locations/
    • Root Path $.records[*]
      • JSON records array contains 90 location objects.
    • Response Mapping locationId -> locationId
      • locationId is in the account schema.

  • Account Aggregation - 2 - Office

    • GET /employees?locationId=$response.locationId$
    • Root Path $.records[*]
      • JSON records array contains an object for each employee.
    • Response Mapping employeeId -> employeeId
      • employeeId is in the account schema.
    • Parent Endpoint Account Aggregation - 1 - Locations

  • Account Aggregation - 3 - People

    • GET /employees?employeeId=$response.employeeId$
    • Root Path $.records[*]
      • This call always returns the single employee in the records array.
    • Response Mapping employeeExternalId -> employeeExternalId etc.
      • There are 16 JSON attributes mapped to the account schema. They are named in ISC the same way they are named in the JSON objects for simplicity.
    • Parent Endpoint Account Aggregation - 2 - Office

Note: In method 2 I’ve tried making the type of the 3rd ‘people’ step both an ‘account aggregation’, and ‘get object’ http opertaion.

Both methods end up with the same number of ‘accounts’ as there are locations. In other words, if a location had just one employee it shows correctly in the account list, but the locations that return multiple employees all get merged into a single account.

image
image873×268 6.92 KB

I’ve examined bidirectional API captures of each method, and in each case I see all the steps (2 or 3) in each method being called, and the expected data is returned from the API.

It just seem like no matter what I do, that first step expects to collect all possible employee records, and child steps can only add information to that initial set.

TL;DR
I need to make multiple dynamic calls to the /employees endpoint and join them to get a complete list of accounts for this application.

/employees?locationId=1
{
    "records": [
        { "Name": "Sam" },
        { "Name": "Mark" },
        { "Name": "Sally" }
    ]
}
/employees?locationId=2
{
    "records": [
        { "Name": "Mary" }
    ]
}
/employees?locationId=3
{
    "records": [
        { "Name": "Roger" },
        { "Name": "Alice" }
    ]
}

ISC Source Account Result:
Alice
Mark
Mary
Roger
Sally
Sam

2

HI @DeckersKR,

Could you please share the response mapping for this operation? As the multiple users are returned as an array, you might need to use indexing.

E.g: employeeExternalId [*]

3

For future readers…
I was able to get a collective list of accounts by utilizing the partitioning function to treat each location as a partition.

Step 1 (Get Locations)

  • Operation Type: Get Partitions
  • GET /locations/
  • Root Path $.records[*]
  • Response Mapping locationId -> locationId

Step 2 (Get Employees)

  • Operation Type: Partitioned Account Aggregation
  • GET /employees?locationExternalId=$partition.locationId$
  • Root Path $.records[*]
  • Response mapping all user attributes as normal.