Programming Guides › Connector Programming Guide › Implementing Connectors › Representing Target Objects

Representing Target Objects

Each LDAP operation results in a matching method in your connector's attribute style processor being called. These methods are passed an instance of the ObjectInfo class which passes on information about the target object such as its DN (in both connector-speak and LDAP) and a class map that allows easy reference to the target object's class.

Connectors that have special requirements for handling connector-speak Distinguished Names may need to make use of the following extension points:

• Connectors can implement the ObjectInfo createObjectInfo() method in the com.ca.jcs.Connector interface, which allows a connector to add extra annotations to be added via an extension to the ObjectInfo class passed in to each of the do*() methods if desired.
• Specialized ObjectInfo extensions can implement the String getConnectorNativeName() method to return native connector-speak hierarchical names which are not in the standard comma separated format (for example, Lotus Notes Domino uses a '/' separator between naming elements)

  When this method is implemented it may also be useful to implement the ObjectInfo getObjectInfo(LdapDN ldapDn, boolean mapDN) method if you need to do an extra lookup on the endpoint to cache some extra state on your specialized ObjectInfo value.

The following methods also in the com.ca.jcs.Connector interface are also likely to be useful in such cases, so that the CA IAM CS framework services such as reverse associations are accessible:

• convertAttributesFromConnector
• convertDNFromConnector
• convertDNToConnector
• postProcessLdapSearchResult

Also, it may be useful to implement an extension to the com.ca.jcs.converter.connector.DNPropertyConverter class and to register it for use with DN typed attributes in the connector's conf/connector.xml file with XML similar to the code shown next. Note that a plugin will displace an already registered plugin from which it extends, so the following settings cause the LNDDNPropertyConverter to displace the standard DNPropertyConverter (which it extends) registered in server_jcs.xml:

<property name="converters">
	<bean class="com.ca.jcs.cfg.MetaPluginConfigSuite">
		<property name="propertyPluginConfigs">
			<list>
			<bean class="com.ca.jcs.cfg.MetaPluginConfig">
				<property name="pluginClass">
				<value>com.ca.jcs.lnd.LNDDNPropertyConverter</value>
				</property>
				<property name="metadataPropNames">
	<list>
				<value>DNLdapObjectClass</value>
				<value>DNLdapObjectClasses</value>
				<value>isDNAbsolute</value>
				<value>DNTestExists</value>
				<value>DNNameOnly</value>
	</list>
				</property>
			</bean> 

If you need to implement such a converter then pay careful attention to the role of the DNConverterFactory which allows specialized DNConverters to extend the basic converters which are part of the CA IAM CS framework, and hence reuse much of their implementation.

Note: For more information, see Non-homogenous Association Collections.