Conflict Detection and Resolution
This process matches the metadata and rules defined for a project and highlights the specifications that may 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 may 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 will each be listed with the field. Likewise, if a data element resolves to many fields, each field will get the data element/source data identifier listed.
There are two primary reasons why conflicts are reported:
- 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 may 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 modification of a field may be conditional based 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 tie-breakers:
- 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.