Appendix A   The Join Process Operators

This appendix defines the syntax used when configuring the selection criteria for join processes, the method with which data is connected between connector and meta views. These processes include join rules, Distinguished Name (DN) mapping rules, constructed attribute definitions, and attribute flow rules.

In configuring these processes, something to note is that there are operators the data must pass through before being accepted in the target entry. First, they pass through the Format Operators where sub-components of the attributes may be created. Then the selection criteria fields are checked via the Requirements Operators. Once requirements are passed, the data is filtered through the Substitution Operators. This appendix contains discussions on the following:

• Format Operators
• Requirements Operators
• Combining Requirements Operators
• Generic Operators
• Quoting

Format Operators

---

The format operator is an optional field which allows an attribute component from the data source to be divided into sub-tokens (special sequences of characters) as it begins the join process. Generally, the original format of the component (consisting of "parameter=value") is sufficient to use as input to the process. However, occasionally, it is desirable to divide it into sub-tokens, dependant upon the configuration of the external data source. For example, you can format an e-mail address attribute such as given.surname@company-name.com into separate given-name, surname, and company-name sub-tokens.

Format operators are configured as:

{attribute} = %sub-token%,%sub-token%,%sub-token%

The schema attribute must be surrounded by curly-brackets ( "{" and "}" ) and tokens must be surrounded by percent characters ("%"). An example would be:

{description}=%given%,%surname%,%company-name%

---

Caution

Please note the formatting of the token list. Each sub-token must be separated by a comma with no other spacing. Deviation from this format will result in failure of the process.

---

Requirements Operators

---

The requirements operator determines whether the data source and/or the target entry meet the conditions set forth by the selection criteria. (Information on how to configure the selection criteria can be found in "Creating the Join Engine Instance"".) If either of them does not meet the required conditions, the entry will not sync and the join process for that particular entry will fail.

Requirements operators specify token conditions in addition to those mentioned under Format Operators. They are as follows:

• Character arrays start at position 1, not 0.
• Word and character operators can be combined. For example, '%given%{2}[1]' identifies the first character of the second word of the given name token.
• Where sets of characters are specified, you can specify a range of values with a dash separator sequence ( "-" ). For example, a-z means all characters beginning `a' through `z'. Also, the terminating character must be the same type as the initial character. For example, `a-9' has no meaning. (If the dash separator is to be used, you must format it with an initial # construction function, i.e.: #a-z.)

Although selection criteria can be configured automatically through the graphical user interface of the Meta-Directory > Configuration window, provided below is a listing of the operators that lie beneath the gui.

Table A-1    Presence functions

Operator	Description	Example
!	Token is empty	%c%!
=@	Token is present	%s%=@

Table A-2    Token length functions

Operator	Description	Example
#=	Token length equals	%s%#=10
#>=	Token length is greater than or equals	%g%#>=2
#>	Token length is greater than	%i%#>1
#<=	Token length is less than or equals	%cn%#<=15
#<	Token length is less than	%i%#<2

Table A-3    Word count functions

Operator	Description	Example
$=	Token word count equals	%cn%$=2
$>=	Token word count is greater than or equal	%s%$>=2
$>	Token word count is greater than	%g%$>2
$<=	Token word count is less than or equals	%cn%$<=2
$<	Token word count is less than	%g%$<2

Table A-4    Token comparison functions

Operator	Description	Example
+	Token begins with string	%cn%+id
-	Token ends with string	%g%-xyz
==	Token matches exactly	%cn%==mailer-daemon
!=	Token does not match	%surname%!=smith
^	Token contains string	%s%^administrator
~	Token does not contain string	%cn%~id

Table A-5    Token construction functions

Operator	Description	Example
.^	Token contains characters	%g%.^z
.~	Token does not contain characters	%s%.~1-9
.#	Token is composed of	%s%.#a-zA-Z
{i}	Token word at index `i'	%g%{2}#>=2
[i]	Token character at index `i'	%g%[1]==a
[i,c]	Token char range at `i', take `c'	%g%[1,4]==reat

Table A-6    Examples of combining requirement operators

Logical Operator	Example
AND	((%given%#>=2)AND(%last%==smith))
OR	((%last%==smith) OR ((%last%==jones))
XOR	((%last%==smith) XOR (%last%==jones)) AND (%given==Tom))
NOT (!)	(!((%last%+Mc) OR (%last%+Oí)))

Combining Requirements Operators

You can combine multiple requirements operators into a single operator by listing them in a semicolon-separated, multi-valued list. Multiple requirements are treated as logical ANDs; that is, all requirements must evaluate to TRUE.

You can specify additional logical operators within individual requirement strings. Each sub-requirement must be encapsulated within parenthesis, and there is no limit to the level of nesting or the number of operators that you can specify. Evaluation of logical operators will be equivalent to the ansi-C precedence and evaluation mechanisms.

Table A-7    Examples of combining requirement operators

Logical Operator	Example
AND	((%given%#>=2)AND(%last%==smith))
OR	((%last%==smith) OR ((%last%==jones))
XOR	((%last%==smith) XOR (%last%==jones)) AND (%given==Tom))
NOT (!)	(!((%last%+Mc) OR (%last%+Oí)))

Substitution Operators

---

The substitution operator builds a search string which looks for entries that match the query in the target view. Substitution rules, using a combination of field codes and token identifiers, produce the resulting string, taking into account criteria from the previous operators. If no matches are found, the join rule fails.

Word, character, and substring operators as defined in Table A-8 are applicable to substitution strings.

Table A-8    Word, character, and substring operators

Operator	Description	Example
{i}	Token word at index `i'	%g%{2}#>=2
[i]	Token character at index `i'	%g%[1]==a
[i,c]	Token char range at `i', take `c'	%g%[1,4]==reat

Generic Operators

---

Besides the strings described in the sections above, you can apply the following operators to any token value.

Table A-9    Generic operators

Operator	Description	Example
<U>	Uppercase string	%g%<U>
<L>	Lowercase string	%g%<L>
<F>	Friendly string	%g%<F>
<A>	Translate to 7-bit US ASCII	%g%<A>.%s%<A>

Specific syntax guidelines are as follows:

• Combining two operators

To use two operators together, you need to group them within one set of angle brackets. For instance, to use the <L> and <A> operators together, you need to group them as <LA>, not <L><A>.

• Friendly string

Friendly string means to capitalize initial and all other characters preceded by a linear white-space character. For instance, 'john joe l.' becomes 'John Joe L.'.

• 7-bit ASCII

Translating to 7-bit ASCII is useful when downgrading from 8-bit and 16-bit character sets to 7-bit RFC-822 addresses. Downgrading rules are not configurable, but will apply intelligence when selecting equivalent 7-bit ASCII characters, the default downgraded character being '-'.

For example:

{L}=%g%.%s%

{L}=%g[1,2].%s[L]

{CN}=%g[F] %i[F] %s[F]

Quoting

---

Quoting characters control the parsing and evaluation of a string. Quoting any character with a backslash (\) removes the possibility of programmatic interpretation from certain delimiter and token constructor characters. Some of these characters are shown in Table A-10.

Table A-10    Quoting characters

Character Type	Character
Delimiter	;
Delimiter	%
Token constructor	.
Token constructor	[