What is the difference between Metadata and Property tags in the Data Model metadata.xml file?
The properties and classes describe the actual data model and closely relate to the LDAP schema (for example, objectclass eTDYNAccount has a string attribute named eTDYNAccountName). These can then have metadata property settings specified that spell out specific details regarding their behavior affecting various sections of the architecture. For example, eTDYNAccount maps to database table accounts, and eTDYNAccountName is its naming attribute.
Some metadata settings are only relevant to specific layers of the architecture (for example, connectorMapTo= is only important to CA IAM CS) whereas the data model itself is relevant to all layers.
Is there any documentation on the connector.xml file?
This file is turned into a com.ca.jcs.ImplBundle JavaBean by the Spring XML Framework. The best reference is the CA IAM CS Javadoc for this class and all the child classes it references. Look for the class names passed as arguments to <bean class=" within the connector.xml file.
The connector.xml for the SDK sample connector also contains some instructional comments. One of the most important parts of the constructed JavaBean is the configuration JavaBean for the connector itself, which is an instance of a class extending com.ca.jcs.meta.MetaConnectorConfig. If you are writing a connector which requires some extra custom configuration settings not offered by the MetaConnectorConfig base class, then write your own class to extend it. Configure it automatically using Spring XML by changing the class name specified to the matching <bean class=" construct in connector.xml. Then, and add extra XML to set the values of the fields you added to your JavaBean.
What is connectorTypeClass?
This field specifies the ConnectorType class for storing data model and opbindings XML metadata documents, and to act as the parental container for all connector instances which are driven them. Connector implementations rarely (if ever) change this setting from com.ca.jcs.meta.MetaConnectorType. An instance of this bean handles LDAP requests targeting the namespace level of the Admin DIT, referred to as the ConnectorType level of the DIT by CA IAM CS.
What is the difference between the server_osgi_*.xml files and connector.xml?
These files share some similar content (like validator and converter plug-in configuration) and both are read and converted into JavaBean instances by Spring XML.
However, the server_osgi_*.xml files deal with global configuration for all ApacheDS and CA IAM CS settings across the whole server (including plug-ins which have global scope). Connector.xml deals with configuration for each specific connector implementation (and configured plug-ins are visible to it alone).
Note: For information about the five server_osgi_*.xml files, see Configuration Files for CA IAM CS in the Connectors Guide.
Is there any documentation on attributes in metadata.xml file?
You can find information about the attributes in the CA IAM CS Javadoc for com.ca.commons.datamodel.MetaDataDefs for CA IAM CS and com.ca.commons.datamodel.DataModelDefs for JIAM, where constants are defined for each standardized setting. You can also add extra per-connector metadata settings, after you have checked the existing standard attributes). In this case, create your own class which defines constants for each of the settings.
Note: For more information, see the example in the SDK sample connector com.ca.jcs.sdk.MetaDataConsts class.
Is there any documentation on attribute connectorMapTo?
See the CA IAM CS Javadoc in the CA IdentityMinder bookshelf for com.ca.commons.datamodel.MetaDataDefs and look for the matching constant MD_CONN_MAP_TO. Pay attention to the related settings MD_CONN_MAP_ALIAS and MD_CONN_MAP_TO_AMBIGUOUS.
Which attributes do I need to add after translation parser table into metadata? Only the connectorMapTo attribute, or are others also required?
You are likely to need additional settings from the CA IAM CS Javadoc for com.ca.commons.datamodel.MetaDataDefs for CA IAM CS and com.ca.commons.datamodel.DataModelUtil for JIAM.
Note: For more information, see the preceding question.
My connector has an LDAP objectclass or attribute names which potentially map to multiple connector names. What should I do?
The following can be used in this case to specify such a relationship:
The CA IAM CS framework then takes care of the required handling.
There can be a considerable performance penalty when trying to determine the connector DN for a provided LDAP DN, especially where there are multiple levels of containers.
How does my connector deal with case sensitivity in the endpoint system?
Use the ConnectorConfig.setCaseSensitive() method which is configured using conf/connector.xml - for example the SDKDYN sample connector sets it to true as follows:
<property name="caseSensitive">
<value>true</value>
</property>
Also note that the SDKFS connector demonstrates the case-insensitive case, which means that all native class and attribute names are converted to lowercase before performing lookups of associated metadata. In the case sensitive case class and attribute names returned by the endpoint system must exactly match the names provided in the metadata document.
How can I validate data passed to and from my connector?
The settings validateToConnector and validateFromConnector in your conf/connector.xml control whether all registered validators triggered by available metadata are executed. Never set validateToConnector=false outside of development because a false setting turns off all validation of LDAP information being passed to your connector.
validateFromConnector defaults to false. If you suspect bad data either preexists or is being written to the endpoint system by another interface, in which validation is performed on query results before they are returned to the client, you can set validateFromConnecto to true.
How do I write and register a custom validator/converter plug-in?
The Plug-In Classes, and the SDK sample connector code have examples of both.
Why document implementing operations? Are they not described in metadata?
In implementing attribute-style processing driven by the data model metadata, there is still a need to write code to interface with the endpoint system. Where the endpoint system supports method-style processing (like JDBC stored procedures), you can write this code in a language other than Java. You can then use opbindings metadata to instruct CA IAM CS how to call it. You can also use opbindings and write this code in a scripting language like JavaScript.
Note: For more information, see Writing Scripts.
|
Copyright © 2013 CA.
All rights reserved.
|
|