Programming Guides › Connector Programming Guide › The Object Model › Metadata Definition › Container Definition

Container Definition

When you are defining metadata mappings for classes which are containers (that is, they can contain objects of other classes and other containers), consider the following points:

• Containers can be mapped like any other class, and have any number of attributes mapped (including ambiguous mappings). A crucial difference is that containers have a childTypes metadata setting which list the names of the LDAP class names which the container is permitted to contain. As the deprecated isContainer=true metadata setting is no longer used, confirm that childTypes is defined. Also confirm that it contains all class names which can appear as children, including possibly the container class itself where nesting is permitted. If class names are missing then objects with these classes will not appear in the results of search operations.

  Note: This setting is of critical importance for all containers, whether real containers or Virtual Containers.

• The top level eTDYNDirectory class acts as a container itself and will consequently need a childTypes setting which names all of the container classes which can appear as its direct children (regardless of whether they are real containers or Virtual Containers).
• If the endpoint is hierarchical, define a mapping to a class that actually exists on the endpoint, as compared to Virtual Containers.
• Use ambiguous mappings if there are multiple varieties of containers and you want to simplify the view you present to clients of the connector. For example, mappings for the JNDI connector often use a connectorMapToAmbiguous setting for eTDYNContainer.

  Note: For more information, see the JavaDoc in the CA IdentityMinder bookshelf.

• If the endpoint is flat, then define Virtual Containers as a way of grouping objects of each class and providing a cleaner view of the endpoint for the customer. These containers are virtual because they do not actually exist on the endpoint, but are an abstraction introduced by CA IAM CS.

  For backward compatibility, you can define Virtual Containers in a connector's connector.xml file, however this is deprecated in favor of defining virtual containers in metadata.

• Map every container class, whether real or virtual, to one of the eleven container classes available. For example, eTDYNContainer and eTDYNContainer001-010.
• Avoid implementing a containerList attribute which lists all the containers under a parent container (or your root connector). Doing this breaks the LDAP containment model, as asking for attributes on the parent object involves searching for all children. Instead, inform the Provisioning Server whether the search targets containers the customer has asked to manage (the default) or all containers that exist on the endpoint. Include eTAgentOnly in the searches requested return attributes.