Configuring Multiple Get Partitions Operations

The user interface of IdentityIQ enables you to configure multiple Get Partitions operations. For parent-child relationships, multiple HTTP calls must be made to build the internal content of Partition maps. The user interface, however, doesn't require the parent-child relationship to be specified.

Note
It is not recommended to use multiple peer Get Partitions operations. Ensure that this configuration returns partition maps containing consistent fields produced by the different operations.

For example:

Copy 
{
"name": "Department 417",
"departmentNumber": "D-417"
}
{
"name": "Cost Center CC-12",
"costCenter": "CC-12"
}

These two types of Partition maps are discouraged because there is no mechanism to map these different types of partitions over to Partition Account Aggregation operations that handle the presence or absence of specific fields in the partition’s map. This could be handled in a Before Operation rule that modifies the URL.

Using the Before Operation Rule to that level of complexity is certainly possible, but is not fully supported.

Note

  • If the same partition fields are configured for static and dynamic partitioning, then the data will be aggregated twice. This is considered an aberrant configuration. Currently, the connector can't display warnings on duplicate partitions, nor can it remove duplicate partitions.

  • If static and dynamic are set to return different fields, like costCenter and userType, then the connector must use a Before Operation rule to handle the URL substitution and/or in the POST body generation.