Attribute Configuration File Format

The abbreviation field specifies the attribute type abbreviation to be used for the attribute. The meta controller uses the specified abbreviation in its attribute mapping operations. The field syntax is:

Abbr:abbreviation

For example:

Abbr:SN

For attribute configuration files that are to be used with LDAP connections to the Identity store, abbreviation must be a valid LDAP attribute name. For example,

Abbr:objectClass

See the String Representation for LDAP Binds chapter for more details about valid LDAP attribute names.

The name field specifies a descriptive name for the attribute. The field syntax is:

Name:name

For example:

Name:Surname

The purpose of this field is to make the attribute configuration file records easier to read; the meta controller does not use this field in its operations.

The prefix field specifies the start tag, if any, that is used in the connected directory data file to identify the start of the attribute’s definition. Prefix tags are generally used in directory data files that use a tagged format. The field syntax is:

Prefix: '[prefix]'

where prefix is one or more characters enclosed in single quotation marks.

For attribute configuration files that are to be used with LDAP connections to the Identity store, prefix is the attribute abbreviation followed by an equal sign: abbreviation*=*. For example,

Prefix:'surname='

If the value of prefix is a non-printing character, supply the octal representation that corresponds to the character. For example, to represent a line feed, define the field as:

Prefix:'\012'

If a prefix is undefined for the attribute (because the associated data file is untagged), specify only the single quotation marks ('') in prefix. For example:

Prefix:''

The following example defines attributes for a connected directory that uses LDAP prefixes:

The suffix field specifies the end tag, if any, that is used in the connected directory data file to identify the end of the attribute’s definition. Suffix tags are generally used in directory data files that use a tagged or an untagged format. For a CSV data file the suffix fields define the separator (e. g. comma or pipe character) and they must be identical for all attributes. The field syntax is:

Suffix: '[suffix]'

where suffix is one or more characters enclosed in single quotation marks.

If the attribute configuration file is to be used with LDAP connections to the Identity store, specify an empty value for suffix ('').

If the value of suffix is a non-printing character, supply the octal representation that corresponds to the character. For example, to represent a line feed, define the field as:

Suffix:'\012'

The following example defines attributes in a connected directory data file that uses a CSV format:

The attribute length field is an optional field used to process connected directory data files that are formatted as fixed-width tables. The field syntax is:

Attrlen:max_data_length

where max_data_length is the maximum number of columns occupied by the attribute definition in the table. For example:

Attrlen:15

The following example defines attributes in a data file with a fixed-width table format that uses no delimiters between attribute records:

The multivalued attribute separator specifies the string, if any, that is used in the connected directory data file to separate multiple attribute values for the attribute. The field syntax is:

Rec-Sep:'[separator]'

where separator is one or more characters enclosed in single quotation marks (' ').

If the value of separator is a non-printing character, supply the octal representation that corresponds to the character. For example, to represent a line feed, define the field as:

Rec-Sep:'\012'

If a multivalued attribute separator is undefined for the attribute, specify only the single quotation marks (' ') in separator. For example:

Rec-Sep:''

The semicolon (;) is used as multivalued attribute value separator in an LDAP attribute configuration file.

The matching rule field defines the matching rule that the metacp program is to apply when attempting to detect modifications to the attribute. The field syntax is:

Mrule:rule-keyword

Supply one of the following keywords in rule-keyword:

The metacp program uses the matching rule field to determine how to identify differences between the attribute in the connected directory and the attribute in the Identity store. If no matching rule is defined for the attribute, the meta modifyentry operation compares the two attributes using CIM. If it detects differences, it sends an obj modify operation that specifies -removeattr attribute_type, -addattr attribute_values to the Identity store because the server has no matching rule for the attribute. If a matching rule exists, meta modifyentry compares the two attributes, and sends an obj modify operation that specifies -removeattr old_value -addattr new_value to the Identity store if it detects differences.

The matching rule field is only relevant to attribute configuration files that define LDAP attributes.

The following example illustrates the use of the matching rule field for a set of attributes:

The encryption field is optional and used to define whether an attribute value needs to be decrypted before the value is sent to the LDAP server. That field is only used in the attribute configuration file describing the attributes of the LDAP directory, e.g. “ldapattr.cfg”.

If set to Y, then the attribute value will be decrypted; if set to N, the attribute value will be taken as it is.

The following example illustrates the use of the encryption field for a set of attributes:

Abbr:postalCode Name:Postal-Code Prefix:'postalCode=' Suffix:'' Rec-Sep:';' MRule:CIM Encryption:N
Abbr:title Name:Title Prefix:'title=' Suffix:'' Rec-Sep:';' MRule:CIM Encryption:Y

Note: This feature is only available, if the meta controller is invoked by the Server (IDS-C) and the Server (IDS-C) provided the environment for performing decryption tasks.

The record separator field defines information that the meta controller is to use to distinguish between entries in a connected directory data file. The field syntax is:

Record-Sep:'separator'

where separator is one or more characters (or the octal representation of one or more characters) enclosed in single quotation marks (' ')

The record separator provides the meta controller with a global indicator that it can use to detect the start of the next entry in a data file. The purpose of the indicator is to permit the meta controller to go to the next entry if it is unable to process the current one. If the record separator field is not specified in the attribute configuration file, the meta controller uses '\n' to distinguish between entries.

The following example defines the line feed as the record separator for a data file:

Record-Sep:'\012'

For XML file format, the record separator must be set to the value entry.

The field separator field defines information that the meta controller is to use to distinguish between attribute values in entries within a connected directory data file that uses a tagged format. The field syntax is:

Field-Sep:'separator'

where separator is one or more characters (or the octal representation of one or more characters) enclosed in single quotation marks (' ').

The field separator is used only in tagged data files to skip attributes in the data file that have not been defined in the attribute configuration file. The field separator permits the meta controller to go to the next attribute if it is unable to process the current one. The field separator is not used as an attribute value separator in an untagged (CSV) data file.

The following example defines the comma as the field separator for a data file:

Field-Sep:','

For XML file format, the field separator must be set to the value newline (\012).

The prefix Base 64 field defines information that the meta controller is to use to identify a base64-encoded LDIF attribute using the attribute’s private prefix followed by this global prefix information. The field syntax is:

Prefix (Base-64):'separator'

where separator is one or more characters (or the octal representation of one or more characters) enclosed in single quotation marks (' '). If this field is not set, the meta controller uses only each attribute’s private prefix when it parses the data file.

The following example defines the colon (:) as the character sequence that is combined with an attribute’s private prefix:

Prefix (Base-64):':'

The comment field defines information that the meta controller is to use to identify comment lines in an LDIF-formatted connected directory data file or any other connected directory data file. The field syntax is:

Comment:'marker'

where marker is one or more characters (or the octal representation of one or more characters) enclosed in single quotation marks (' '). The following example defines the # character as a comment marker:

Comment:'#'

The continuation line field defines information that the Identity controller is to use to identify continued lines in an LDIF-formatted connected directory data file or any other data file with continuation lines. The field syntax is:

Continuation-Line:'marker'

where marker is one or more characters (or the octal representation of one or more characters) enclosed in single quotation marks (' '). The continuation line marker is only recognized at the beginning of a line. Consequently, the marker is the indication in a line that this line is a continuation of the preceding line. The following example defines the space as a continuation line marker:

Continuation-Line:' '

The enclosing sequence field defines a marker that the meta controller is to use identify the start and end of an entry in a connected directory data file. The field syntax is:

Enclosing-Sequence:'marker'

where marker is one or more characters (or the octal representation of one or more characters) enclosed in single quotation marks (''). When the meta controller encounters the enclosing sequence marker during its parsing of the data file, it searches for the next occurrence of the enclosing sequence marker and treats everything between the two markers as one entry. The definition of an enclosing sequence marker is useful for parsing untagged data files, especially CSV-formatted files such as Microsoft Exchange data files, where the comma (,) is used as an entry separator but can also be part of an attribute value in an entry.

The following example defines the double-quote (") as an entry boundary marker:

Enclosing-Sequence:'"'

When it encounters two subsequent occurrences of the enclosing sequence marker, the meta controller treats the marker as part of the attribute value. For example, the meta controller parses "data""data" as the value data"data

The operation code field specifies the attribute within an LDIF change file that holds the LDIF change file operation code for an entry in the change file. The field syntax is:

Op-Code Field:abbreviation

where abbreviation is the attribute type abbreviation for the attribute.

In the following example, the attribute LCHNGTYPE is defined as the LDIF change file operation code attribute:

The add modification field specifies the attribute in an LDIF change file that represents the "add" attribute modification operation of an LDIF "modify object" change operation. The field syntax is:

ADD-Modification Field:abbreviation

where abbreviation is the attribute type abbreviation for the attribute.

In the following example, the attribute LADD_OP is defined as the LDIF "modify object, add attribute value" attribute:

The skip lines field defines information that the meta controller is to use if a data file contains a certain number of lines at the beginning of the file that it should not process; for example, the header line with the attribute names generated by the Microsoft Exchange admin program. The number of lines as indicated in Skip Lines is ignored while processing an import data file. The field syntax is:

Skip Lines:integer

where integer is a value that is greater than or equal to 0 and specifies the number of lines from the beginning of the file that the meta controller is to ignore when processing an import file. For example:

Skip Lines:1

directs the meta controller to ignore the first line of the import data file.

The replace modification field specifies the attribute in an LDIF change file that represents the "replace" attribute modification operation of an LDIF "modify object" change operation. The field syntax is:

REPLACE-Modification Field:abbreviation

where abbreviation is the attribute type abbreviation for the attribute.

In the following example, the attribute LMOD_OP is defined as the LDIF "modify object, replace attribute value" attribute:

The delete modification field specifies the attribute within an LDIF change file that represents the "delete" attribute modification operation of an "LDIF "modify object" change operation. The field syntax is:

DELETE-Modification Field:abbreviation

where abbreviation is the attribute type abbreviation for the attribute.

In the following example, the attribute LDEL_OP is defined as the LDIF "modify object, delete attribute or attribute value" attribute:

The new RDN field specifies the attribute within an LDIF change file that represents the "new RDN" parameter in an LDIF "modify DN" change operation. The field syntax is:

New-RDN Field:abbreviation

where abbreviation is the attribute type abbreviation for the attribute.

In the following example, the attribute NEW_RDN is defined as the attribute that holds the new RDN in an LDIF "modify DN" change operation:

The delete old RDN field specifies the attribute within an LDIF change file that represents the "delete old RDN" parameter in an LDIF "modify DN" change operation. The field syntax is:

Delete Old-RDN Field:abbreviation

where abbreviation is the attribute type abbreviation for the attribute.

In the following example, the attribute DEL_OLD_RDN is defined as the attribute in an LDIF "modify DN" change entry that holds the boolean value that specifies whether to delete the old RDN:

The new superior field specifies the attribute within an LDIF change file that represents the "new superior" parameter in an LDIF "modify DN" change operation. The field syntax is:

New Superior Field:abbreviation

where abbreviation is the attribute type abbreviation for the attribute.

In the following example, the attribute NEW_SUP is defined as the attribute that holds a new superior in an LDIF "modify DN" change operation.

The modification separator field specifies the attribute in an LDIF change file that identifies the end of an attribute modification in an LDIF "modify object" change operation. The field syntax is:

Modification-Sep Field:abbreviation

where abbreviation is the attribute type abbreviation for the attribute.

In the following example, the attribute EOA is defined as the attribute that holds the "end-of-attribute-modification" marker in an LDIF "modify object" change operation.

The add op code field specifies the keyword in an LDIF change file that represents an "add object" LDIF change operation. The field syntax is:

Op-Code-ADD:keyword

where keyword is a string. For example:

Op-Code-ADD:add

The keyword supplied in the attribute configuration files corresponds to the keyword that is applied as a value to the LDIF Operation Code attribute in the LDIF change file to indicate an "add object" operation. The definition of this keyword in the attribute configuration file permits the meta controller to recognize an LDIF "add object" operation in an LDIF change file.

The delete op code field specifies the keyword in an LDIF change file that represents the LDIF "delete object" operation code. The field syntax is:

Op-Code-DEL:keyword

where keyword is a string. For example:

Op-Code-DEL:delete

The keyword supplied in the attribute configuration files corresponds to the keyword that is applied as a value to the LDIF Operation Code attribute in the LDIF change file to indicate a "delete object" operation. The definition of this keyword in the attribute configuration file permits the meta controller to recognize an LDIF "delete object" operation in an LDIF change file.

The modify op code field specifies the keyword in an LDIF change file that represents the LDIF "modify object" operation code. The field syntax is:

Op-Code-MOD:keyword

where keyword is a string. For example:

Op-Code-MOD:modify

The keyword supplied in the attribute configuration files corresponds to the keyword that is applied as a value to the LDIF Operation Code attribute in the LDIF change file to indicate an LDIF "modify object" operation. The definition of this keyword in the attribute configuration file permits the meta controller to recognize an LDIF "modify object" operation in an LDIF change file.

The modify DN op code field specifies the keyword in an LDIF change file that represents the LDIF "modify DN" operation. The field syntax is:

Op-Code-MODDN:keyword

where keyword is a string. For example:

Op-Code-MODDN:moddn

The keyword supplied in the attribute configuration files corresponds to the keyword that is applied as a value to the LDIF Operation Code attribute in the LDIF change file to indicate a "modify DN" operation. The definition of this keyword in the attribute configuration file permits the meta controller to recognize an LDIF "modify DN" operation in an LDIF change file.

The modify RDN op code field specifies the keyword in an LDIF change file that represents the LDIF "modify RDN" operation. The field syntax is:

Op-Code-MODRDN:keyword

where keyword is a string. For example:

Op-Code-MODRDN:modrdn

The keyword supplied in the attribute configuration files corresponds to the keyword that is applied as a value to the LDIF Operation Code attribute in the LDIF change file to indicate a "modify RDN" operation. The definition of this keyword in the attribute configuration file permits the meta controller to recognize an LDIF "modify RDN" operation in an LDIF change file.

The ignore empty value field controls whether the meta controller returns empty attributes (attributes with no value) in the results of an obj search operation on a connected directory. The field syntax is:

IgnEmptyVal:n

where n is Y to ignore empty attribute values and N to return empty attributes.

Set the IgnEmptyVal field to N when exporting the contents of the Identity store to a connected directory that is a data file with a position-driven (untagged) file format, such as table format or CSV. In this type of data file, the absence of attributes needs to be handled. For example, suppose you are exporting the attributes surname, given-name, and telephone-number to a CSV-formatted data file. Surname and telephone-number have the values Schmid and 41496, and given-name is empty. When IgnEmptyVal is set to N, the meta controller generates the following data on export:

Schmid,,41496

When exporting to a connected directory that is a data file with a tagged format, you can choose to list the empty attributes with the prefix and no attribute value (IgnEmptyVal:N), or to drop empty attributes entirely (IgnEmptyVal:Y). For example, if IgnEmptyVal is set to N, the result is:

If IgnEmptyVal is set to Y, the result is:

If you want the meta controller to write only special attributes as empty to the datafile and not all attributes you can do it the following way:

Setting for example the attribute mail to empty (in dependence of whatever, mostly in case of it is empty after mapping) write in your post join mapping: