Correlation and Confirmation Rules

Waveset matches resource accounts that are not linked to a user with Waveset users in two phases:

• Correlation. Finding potential owners

• Confirmation. Testing each potential owner

A correlation rule looks for Waveset users that might own an account. A confirmation rule tests an Waveset user against an account to determine whether the user actually does own the account. This two-stage approach allows Waveset to optimize correlation, by quickly finding possible owners (based on name or attributes), and by performing expensive checks only on the possible owners.

Reconciliation policy allows you to select a correlation rule and a confirmation rule for each resource. (You may also specify No Confirmation Rule.) The default correlation rule is to look for a user with a name that exactly matches the account ID of the input account. By default, no confirmation rule is used.

Correlation and confirmation rules are also used for discovery and Active Sync.

Waveset predefines a number of correlation and confirmation rules in sample/reconRules.xml. You can also write your own correlation and confirmation rules. Any rule object with a subtype of SUBTYPE_ACCOUNT_CORRELATION_RULE or SUBTYPE_ACCOUNT_CONFIRMATION_RULE automatically appears in the appropriate Reconciliation Policy selection list.

Correlation Rules

A correlation rule can generate a list of user names based on values of the attributes of the resource account. A correlation rule may also generate a list of attribute conditions (referring to queryable attributes of a user object) that will be used to select users.

A correlation rule is run once for each unclaimed account.

A correlation rule should be relatively “inexpensive” but as selective as possible. If possible, defer expensive processing to a confirmation rule.

Waveset predefines several correlation rules in sample/reconRules.xml:

• User Name Matches AccountId. Returns the value of the accountId attribute. It selects as a possible owner any Waveset user with a name that matches the resource account ID. This is the default correlation rule.

• User Owns Matching AccountId. Returns a list of attribute conditions. This will select as a possible owner any Waveset user that owns a resource account that matches the same accountId value.

• User Email Matches Account Email. Returns a list of attribute conditions that will select Waveset users based on the account’s email attribute.

Input for any correlation rule is a map of the account attributes. Output must be one of:

• String (containing user name or ID)

• List of String elements (each a user name or ID)

• List of WSAttribute elements

• List of AttributeCondition elements

A more complicated rule might combine or manipulate account attribute values to generate a list of names or a list of attribute conditions.

Attribute conditions must refer to queryable attributes, which are configured as QueryableAttrNames in the UserUIConfig object.

For example, reconRules.xml contains a fourth sample correlation rule, User FullName Matches Account FullName. XML comments disable this rule, because it will not work correctly without additional configuration. This rule looks for Waveset users based on fullname, but this attribute is not queryable by default.

Correlating on an extended attribute requires special configuration:

• The extended attribute must be specified as queryable in UserUIConfig (added to the list of QueryableAttrNames).

• The Waveset application (or the application server) may need to be restarted for the UserUIConfig change to take effect.

Confirmation Rules

A confirmation rule is run once for each matching user returned by the correlation rule.

A typical confirmation rule compares internal values from the user view to the values of account attributes. As an optional second stage in correlation processing, the confirmation rule performs checks that cannot be expressed in a correlation rule (or that are too expensive to evaluate in a correlation rule). In general, you need a confirmation rule only in the following circumstances:

• The correlation rule may return more than one matching user

• User values that must be compared are not queryable

Waveset predefines two confirmation rules in sample/reconRules.xml:

• User Email Matches Account Email. Returns a value of true if the user’s email matches the account’s email. This illustrates the fact that many ownership decisions could be expressed with either a correlation rule or a confirmation rule. However, since the email attribute of an Waveset user is automatically queryable, it would almost always be more efficient to express this as a correlation rule.

• User First And Last Names Match Account. Uses the XPRESS language to compare the user’s first and last name to the same values of the account.

Inputs to any confirmation rule are:

• userview. Full view of an Waveset user.

• account. Map of resource account attributes.

A confirmation rule returns a string-form Boolean value of true if the user owns the account; otherwise, it returns a value of false.

The default confirmation rule is No Confirmation Rule. This assumes that the correlation rule is selective enough to find at most one user for each account. If the correlation rule selects more than one user, the account situation will be DISPUTED.