Programming Guides › Connector Programming Guide › SDK Sample Connectors › Compound Value Support

Compound Value Support

The SDKCOMPOUND connector demonstrates configuration and use of compound values in a fully functional connector. However, as it has the luxury of storing the compound values as simple strings in property files stored on the CA IAM CS local filesystem, it is able to bypass some of the complexity of compound value support in the JDBC connector where compound values need to be split up and stored in separate database tables.

If you determine that you require compound value support for your connector, consider the following:

• The metadata format (defined in datamodel.xsd) and the CA IAM CS framework impose no restrictions on the level to which compound value classes can be nested. Hence the SDKCOMPOUND connector includes the PersonalizationOption compound value class which demonstrates two levels of nesting. Hence any restrictions are due to either the connector (because of the endpoint system technology) or higher level clients with User Interfaces.
• Compound values can reference other object instances in associations (using DNs for instance), but no other objects can reference them.
• Because the individual attributes in compound values are not represented by LDAP attributes (but rather as values of a JSON object) it is often the case that connectorMapTo settings are not required for them. For this reason the "isCompoundValue" setting (which has a similar effect to connectorMapToSame) signifies that connectorMapTo values need only be provided when a compound attribute's name is unacceptable to the endpoint system. For example, due to restrictions on the characters permitted in SQL column names.
• The CA IdentityMinder user interface imposes a restriction where nested compound values are not displayed. This is not a problem for DYN JDBC connectors but it is a problem for the SDKCOMPOUND connector.
• In CA IdentityMinder Provisioning Manager, nested compound values are not displayed in an intuitive way, that is, user needs to understand JSON syntax.
• The JDBC connector does not support nested compound values as doing so would necessitate support for compound primary keys.

  All schemes are supported for specifying the keys of parent and compound value objects, including generated keys on either or both ends.

  In relational 1:N associations, the table on the "N" side must be responsible for storing the key for the "1" side. Therefore, the table storing compound values needs a column specifying a key for the parent object, and the COMPOUND_PARENT assocType is used on the attribute defining the association between them.

• Both indirect and direct associations are now supported, with metadata specifying which style applies to which attributes. Associations between a compound object and its parent are modeled as direct associations.