Partitioning Aggregation

The Web Services SaaS connector supports partitioning through the following modes:

• Static Partitioning – Define separate partition filters in the User Partitions field to create a User Partitioning Scheme. For more information, refer to Configuring Static Partitions.

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

• 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 in both fixed XML configuration blocks and using dynamic values returned from the remote system. When using both types of configurations, 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 either token substitution in a URL pattern or using a POST payload body's JSON or XML.

For example, the Acme Human Resources department groups account searches by their costCenter attribute. To handle this, they can configure 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 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.