Web Services Connector – Account Aggregation fails with ResultSet / SchemaNotDefinedException in IIQ (ServiceNow sys_user API)

IdentityIQ (IIQ) IIQ Discussion and Questions
,
1

I am working on integrating an application with SailPoint IdentityIQ using the Web Services connector to perform account aggregation. The target system exposes a REST API that returns user data in JSON format (similar to a standard list‑users endpoint), and the API works correctly when tested externally, returning a list of users under a top‑level JSON array. In IdentityIQ, I configured the application with OAuth 2.0 (client credentials), a GET‑based account aggregation operation, and defined an account object schema with basic attributes (such as a unique account identifier and supporting user attributes). I also configured the response mapping to point to the JSON array and mapped individual attributes accordingly.

However, when running the Account Aggregation task, the job fails with errors such as “Unable to create iterator”, “could not extract ResultSet”, or “SchemaNotDefinedException: The schema for objectType account is not configured for this connector”, even though the schema and response mappings appear to be defined. Test Connection succeeds, and the API itself returns valid data, but IdentityIQ is unable to iterate over the response and create account objects. I am trying to understand whether this is a known limitation or configuration nuance of the Web Services connector for GET‑based JSON APIs, or if there are additional required steps (beyond schema definition and response mapping) to correctly enable account aggregation.

image
image1663×808 33 KB

image
image1903×642 21.1 KB

2

Hi Kazi,

The issue looks like the Connector Operations are not configured correctly. Just defining the Schema is not enough. you also need to create an explicit Operation for account aggregation.

Here’s what to check:

  1. Operation Type must be set to “Iterate Accounts” (not left blank or set to Test Connection)
  2. Object Type inside the operation must be set to “account”. this is what links it to your schema
  3. Root Path must point to the JSON array in the response (e.g., result for ServiceNow sys_user API)
  4. Attribute mappings must be defined inside the operation itself, not just in the schema

Without the Operation Type = “Iterate Accounts” and Object Type = “account”, IIQ has no way to know this operation is meant to pull accounts hence the SchemaNotDefinedException even though the schema exists.

Try reconfiguring the operation with these settings and the aggregation should work.

3

The Web Services connector does not use the Schema tab for object type definition. It reads the object type from the connector configuration XML directly.

Go to your Application XML and ensure this exists:

<AttributeDefinition name="objectType" value="account"/>

If it says Account, accounts, or is missing entirely, the connector throws SchemaNotDefinedException at runtime regardless of what the Schema tab shows. Fix it in the XML, save, and re-run.

4

Hi @kazi_1234 ,

Can you share the account aggregation operation, application schema and sample response screenshots

5

Click Add Object Type.
provide account
and then define the schema manually but adding all attribute.
make sure attr names in schema matches with attr name in reponse mapping as well

6

@kazi_1234 You mentioned you have schema defined properly, but it is blank in your screenshot. Could you please reimport your artefacts or check in debug if schema is still defined in app xml, if so, remove the ids and save it one more time.

If issue still persists, please share app xml for review.

7

Can you share your application xml by masking sensitive details ?

8

Verify below details in connector

Step 1: Verify Operation Object Type

Open your Application Configuration in IIQ and go to the HTTP Operations tab.

Select your Account Aggregation operation.

Look at the Object Type field for this specific operation.

Ensure it says account (lowercase, matching standard IIQ schema) or matches whatever you named your schema exactly. If it says User or is blank, IIQ won’t be able to map the incoming stream to the schema you defined, throwing that SchemaNotDefinedException.

Step 2: Configure the Response Mapping Root

The connector needs to know where the list starts. In your Account Aggregation operation, under the Response Mapping section:

Root Path (or Response Element): If your API returns a raw JSON array at the very top level, use $ or /. If your API returns an object like {“users”: […]}, your Root Path must be $.users (for JSONPath) or /users.

Attribute Mappings: Ensure your attributes are relative to this root path. For example, if the root is $.users, the attribute path for the identifier should just be id or $.id, not $.users.id.

Step 3: Check for Paging / “Terminal” Condition

The “Unable to create iterator” error frequently happens if IIQ tries to execute a paging loop and gets stuck, or if it expects a list but receives a single object (or vice versa).

If your API does not use pagination, ensure that the paging configuration on the operation is entirely disabled or left blank.

If it returns a single page and stops, IIQ needs to know it’s a single-shot request, otherwise, the iterator fails on the second (non-existent) page attempt.

Step 4: The Schema Definition

Go to the Schema tab of your application:

Ensure the Object Type of the schema is exactly account.

Ensure the Identity Attribute (e.g., id or username) matches the exact name of the attribute you are extracting in your response mapping.

Summary Checklist for your WS Operation

Configuration Field

Expected Value / Check

Operation Type

Account Aggregation

Object Type

account (Must match Schema name)

Root Path / Context

Set to the base of the JSON array (e.g., $.users or $)

Paging

Disabled (unless explicitly configured with a termination rule)

A Quick Troubleshooting Tip

If you apply these changes and it still fails, turn on specialized logging to see the exact payload IIQ is failing to parse. Add this to your log4j2.properties file:

logger.webservices.name = connector.sdk.webservices
logger.webservices.level = debug

This will print the raw JSON response and the connector’s attempt to parse it directly into the sailpoint.log, allowing you to see exactly where the JSONpath expression is losing its way.