Conflict Detection and Resolution
This process matches the metadata and rules defined for a project and highlights the specifications that might prevent the data disguise from performing properly. The results of the analysis of conflict detection and resolution are presented on the coverage display. Some or all of the detected conflicts might be resolved automatically by the conflict resolution process. When this happens, the specific rules dismissed by resolution will be indicated. If all conflicts are automatically resolved, a user can submit the disguise assured that it is primed for proper execution.
Reporting on the detection of conflicts is done based on a series of tests made against the collections of metadata, data elements, and rules.
Data fields are identified by the source data identifiers (SDIs) inside a data element. If several SDIs resolve to a metadata field, they are listed with the field. Likewise, if a data element resolves to many fields, each field displays the data element/source data identifier listed.
Conflicts are reported mainly for the following reasons:
- Data element conflict because multiple data elements identify the same source field
- Rule conflict because multiple rules are replacing the same source field.
If a source field is identified as being multiple data elements, a data element conflict will be reported. Multiple source data identifiers (SDIs) can identify the same field, but only the SDI that is the most specific will be used. If multiple data elements include SDIs of equal weight, there is no way to determine which SDI to use, so a conflict is reported. To eliminate a data element conflict, either make one of the SDIs in the correct data element more specific, or code an exclusion SDI in the incorrect data element.
If a field is targeted for a disguise by different rules, then a conflict will be reported. This problem is caused when multiple rules change data for the same data field. You might need to change a rule to eliminate one of the data elements that resolved to this field.
It is important to note that within a single rule, many references to modify a field can be legally coded and will not cause a conflict. This is allowed with the expectation that modifying a field might be conditional on criteria coded in the rule expression.
Runtime exception: Special processing is performed when a targeted field is a logically related field in another metadata. These logically related fields must be processed in the exact same manner to maintain the relationships in the data. These fields will be "tied" to each other by means of a logically related thread. No other rule actions will be allowed against these related fields.
Resolving conflicts when possible, promotes the most detailed rule and eliminates the conflicting rules based on these tiebreakers:
- Rules that are processed as part of a logical relation thread are given priority over all regular user-defined rules.
- User rules with more field dependencies take precedence over rules with fewer field references. Resolution processing will select the rule with the most available fields referenced in the rule (unless a relation thread promoted a rule that is already selected).
Without distinct differences in the rules that have targeted a given field, the disguise will be considered in error. Messages provide the information to explain the "collisions" on the targeted field.
Propagation rules
BMC AMI File-AID/RDX generates propagation rules from table relationships. When table relationships are used with data privacy rules, propagation rules supersede other non-conflicting rules when the other rules consistently disguise the same source values as the target values. For example, if a rule has only one encryption rule action, the disguised values of related fields are the same, so the propagation rules will provide the same result for all related fields. When rule logic defines a rule, File-AID Rules Engine (FARE) cannot determine whether the propagation rules and Dynamic Privacy Rules (DPRs) will disguise the same source values into the same target values. Though the propagation is sourced from the same disguise rule on a different field, conditional rule logic can affect the target value. When precedence of one rule cannot be determined, as in the case of rule logic, the disguise is considered an error. In such scenarios the conflict between the propagation rule and another rule are not resolved automatically and an error occurs.