Partitioning

The Web Services Connector supports partitioning through the following modes:

  • Static Partitioning – Defines the separate partitions through fixed mappings via API from the backend only.

    Note
    Use SailPoint - Beta SaaS API to update the source with Static Partitions along with other configuration.

    Select Configuring Static Partitions to move to the needed section within this page.

  • Dynamic Partitioning – Discovers partitions at run time based on information returned by a REST or Web Services API call from a remote system.

Static and Dynamic partitioning modes can be used at the same time. Partitions can be defined both in fixed XML configuration blocks and by dynamic values returned from the remote system. When both types of configurations are used, the list of partition records are concatenated and all of the defined partitions are aggregated.

Conceptually, each partition retrieves the accounts from the managed system that correspond to a specific field or field values. The connector expects that those values can be passed to a search or filter API exposed by the managed system. The connector supports partitioning through token substitution of a URL pattern and/or a POST payload body's JSON or XML.

For example, the Acme Human Resources department groups account searches by their costCenter attribute, and configures the API to return accounts using the following configuration:

GET https://acme-hr.com/admin/listAccounts?costCenter=AdminHQ

In this example the API returns account records which belong only to the "AdminHQ" cost center.

Assuming an even distribution of accounts to various costCenter values, each value for the costCenter attribute in this example can be mapped to a partition that aggregates the accounts corresponding to that grouping. Each partition is effectively a map of key-value pairs that define a unique grouping of accounts.

The partition's key-value pairs are exposed to the Before/After Rules of a Connector Operation. They are available in the Context URL field, which is appended to the request and in the body text of a POST operation. In the Context URL the partition to aggregate is exposed as the $partition.*$ keyword, where the asterisk (*) is replaced by the field name from the partition. This behaves similarly to the $response.* keyword and other tokens used by the Web Services connector.

For example, in a partitioned account aggregation type of operation, you could have a Context URL as follows:

https://acme-hr.com/admin/listAccounts?costCenter=$partition.costCenter$

When evaluated during aggregation, the partition's costCenter value is substituted for the $-encapsulated field and is then passed to the remote system. In situations where a simple path substitution is not sufficient, the URL can be generated in the Before Operation Rule by modifying the request endpoint's URL field. The partition variable is exposed in the Before Operation Rule for use by connector-specific rule logic.