Skip Headers
Oracle® Communications Network Integrity Developer's Guide
Release 7.1

E23701-03
Go to Documentation Home
Home
Go to Book List
Book List
Go to Table of Contents
Contents
Go to Feedback page
Contact Us

Go to previous page
Previous
Go to next page
Next
PDF · Mobi · ePub

11 Working with Discrepancy Detection Actions and Processors

This chapter provides information about Oracle Communications Network Integrity discrepancy detection actions and processors.

Discrepancy Detection Action

The discrepancy detection action is a Network Integrity operation that compares discovery and import scan results, and reports on their differences by generating discrepancies.

A detection action triggers to run immediately following a discovery, import, or assimilation scan run. (Select the Detect Discrepancy check box in the scan configuration to set the trigger.) The entity results from the triggering scan run become the Compare entities for the detection action. The action then uses a matching algorithm to find from the other side, and precedes with the comparisons.

See "About the Compare and Reference Sides" for a fuller description of the two sides of entities of discrepancy detection.

See "About the Base Detection Cartridge and the Default Comparison Algorithm" for a description of the comparison algorithm.

Create a discrepancy detection action whenever new discovery, import, or assimilation actions are created, because every detection action is configured to receive results from specific actions only. See "Result Source" for more information.

About Discrepancy Detection

Discrepancy detection triggers immediately after a scan is finished. A scan is configured to use a single type of action, and therefore only generates Discovery results (representing network entities) or Import results (representing inventory system entities). Therefore, when the discrepancy detection action triggers, it has immediate access to one side of results: the compare entities.

For the other side of the results, the detection action searches the Network Integrity database for results with the following criteria:

  • The results must come from the opposite system from the triggered scan. For example, if the detection action triggers from a Discovery action scan, then the detection action searches the database for Import result.

  • The results have a matching name and result category (as configured by Result Source).

  • The results must come from the most recent scan result.

If no matching results are found, then EXTRA_ENTITY discrepancies are generated for each root entity on that result.

Creating a Discrepancy Detection Action

See Design Studio Network Integrity online Help for information on creating actions.

Discrepancy Detection Action Editor

The Discrepancy Detection Action editor has the following five tabbed pages:

  • Details: For discrepancy detection actions, you can edit the Description, Implementation Prefix, Abstract setting, and Documentation text. See the Common Fields for Details Tab section.

  • Processors: The only processor type allowed to be created and used is the Discrepancy Detection Processor. See the Processors Tab and Common Fields for Processors Tab sections.

  • Model: See the Model Collection and Common Fields for Model Tab sections for more detail.

  • Result Source: Specifies the input result categories for the action to act upon.

  • Conditions: See the Conditions and Common Fields for Conditions Tab sections for more detail.

Result Source

The Result Source table specifies a list of scan actions that can trigger a Discrepancy Detection Action. The triggering action must be a discovery, import, or assimilation action. By default, results from all categories are included in the discrepancy detection. It is possible to choose a subset of the categories to apply the discrepancy detection.

For example, Figure 11-1 illustrates a Cisco router discovery action that produces results in 2 categories: Device and VPN. Two separate detection actions are written to compare the results. Each detection action specifies a result source with the same Action, but different result category. For example, the Device Discrepancy Detection Action receives results of Device category only.

Figure 11-1 Discrepancy Detection Actions (Example 1)

Illustrates discrepancy detection action

A Result Source that does not specify a Result Category matches every Result Category generated by the scan Action. Figure 11-2 illustrates a Cisco Discrepancy Detection Action that receives both Device and VPN categories of results.

Figure 11-2 Discrepancy Detection Action (Example 2)

Illustrates discrepancy detection action

The Result Source is a mandatory field; there must be at least one entry in the table. Design Studio marks the Discrepancy Detection Action with an error during a project build if the table has no entries.

Caution:

No two discrepancy detection actions can have the same Label and Result Source.

About Result Source and Scan Types

Typically a Result Source configuration detection action has a single action as the result source: usually the Discovery action. This detection action triggers when an Integrity Scan is configured using that exact Discovery action, and the Detect Discrepancy option is checked. This detection action does not trigger by scans configured with any other Discovery or Import action. Do not set the Detect Discrepancy option on the Import scan, because this might not trigger a detection action at all.

Generated Action MDB and Controller

The Detection Action is implemented as an MDB. Please see the Generated Action MDB and Controller subsection of the General Introduction to Actions section for more information.

Discrepancy Detection Processor

The Discrepancy Detection Processor is the atomic sub-function of a Discrepancy Detection Action. The typical tasks of a detection processor are different than the scan-related Processors (Discovery, Import, and Assimilation) and include the following:

  • create and add filters to alter the default behavior of the base Discrepancy Detection Action

  • perform post-processing on the set of discrepancies produced by the base Discrepancy Detection Action

See the section "Discrepancy Detection Processor Patterns" for more information on the various patterns for detection action-processor implementation.

Creating a Discrepancy Detection Processor

See Design Studio Network Integrity online Help for information on creating processors.

Implementation Interface

The processor implementation class derives from a Studio-generated interface class. There is a single abstract method that the implementation class must implement. The abstract method has the following interface:

public <Processor_Name>Response invoke(
             DiscrepancyDetectionProcessorContext context,
             <Processor_Name>Request request)
        throws ProcessorException
        {
        }

Input Parameters of Invoke()

Table 11-1 shows the first parameter, context, that provides the following methods:

Table 11-1 Context Method and Return Type

Context Method Return Type Description
getActionName()

String

Getter for the name of this Action.

addDiscrepancy(
    DisDiscrepancy discrerpancy
)

void

Adds a new discrepancy into the result set.

getDiscrepancies()

Collection<DisDiscrepancy>

Returns the set of result discrepancies added so far.

persistDiscrepancies()

void

Writes the set of result discrepancies into the database.

findReferenceRoot(
    DiscrepancyEnabled compareEntity
)

DiscrepancyEnabled

Returns the referenceEntity that matches all criteria of the input compareEntity.

getRootEntityLoader()

RootEntityLoader

(For advanced use only.) Returns the root entity loader that gets all the root entities on the result group on the compare side. Root entities are the starting entities of the comparison process.

getDiscrepancyDetector()

GenericDiscrepancyDetector

(For advanced use only.) Returns the discrepancy detector object that starts off the comparison process.

isCompareRoot(
    DiscrepancyEnabled compareEntity
)

boolean

(For advanced use only.) Returns true if the input entity is a Compare Root Entity. Root entities are the starting entities of the comparison process.


In addition, the context can be cast into class BaseDiscrepancyDetectionController (package oracle.communications.integrity.scanCartridges.sdk) that makes the method in Table 11-2 available.

Table 11-2 Context Method and Return Type

Context Method Return Type Description
getResultGroup()

DisResultGroup

Getter for the compared-side Result Group (the overall container of entities to be compared).


The request parameter contains getters for each item in the Input Parameters table of the Context Parameters tab of the processor editor. It also contains a getter to retrieve the groups and items listed in the Properties tab.

Return Type of Invoke()

The return type of the invoke() method varies depending on the Output Parameters setting in the Context Parameters tab page.

If there is no output parameter, the return type is void.

If there are one or more output parameters, the return type is a generated class with the name <Processor_Name>Response. This Response class has getters and setters for each item in the Output Parameters table of the Context Parameters tab of the processor editor.

Discrepancy Detection Processor Patterns

There are several patterns of processor used inside a discrepancy detection action. Each successive pattern introduces a new level of flexibility, power, and complexity. The patterns are listed below, in order from the simplest to the most complex:

  1. Reusing the base Detect Discrepancy Action.

  2. Adding new filters and handlers.

  3. Adding post-Processors.

Reusing the Base Detect Discrepancy Action

This usage pattern provides a baseline comparison algorithm between the compare and the reference sides. A detection action using this pattern has the ability to compare exact entity attributes and associations, and can generate five of the seven types of discrepancy. (Ordering Errors and Association Ordering Errors are not detected by the baseline comparison algorithm, because it assumes that there are no ordered relationships.)

To use this pattern, use following steps:

  1. Import the Base Detection Cartridge into the Studio Project environment. This cartridge contains a reusable detection action called Detect Discrepancies.

  2. Create a Discrepancy Detection Action.

  3. In the Processors tab, add the Detect Discrepancies action. This action adds a single processor, Discrepancy Detector, into the table.

  4. Set the Result Source for this action.

Figure 11-3 shows the content of the processors tab for a detection action using this pattern.

Figure 11-3 Processor Tab Detection Action

Shows Processor Tab Detection Action

About the Base Detection Cartridge and the Default Comparison Algorithm

The Base Detection cartridge contains a reusable Discrepancy Detection Action called Detect Discrepancies. This action is abstract, and cannot be deployed by itself. It is intended to be imported by virtually all other Discrepancy Detection Actions. This action implements a general comparison algorithm that can work with all entity types and specifications, and can detect and report all seven types of discrepancy.

This ability enables a cartridge developer to build a working discrepancy detection cartridge for arbitrary discovered data without writing code. Its behavior is customizable, by using the techniques described in the following processor patterns.

The default comparison algorithm is outlined below.

  1. The detector loops over the compare root entities.

  2. The detector checks if each compare root entity should be considered for discrepancy detection. If it should not, the root entity is ignored, and the detector begins processing the next compare.

  3. A rootEntityHandler finds the matching reference root entity for the compare root entity. The default rootEntityLoader uses the Name field to find the matching reference root entity. If no reference root entity is found, an EXTRA_ENTITY discrepancy is generated.

  4. The attributes of the matching entities are compared, and an ATTRIBUTE_VALUE_MISMATCH discrepancy is generated for each attribute with different values. If an attribute contains an ordered list of values, an ORDERING_ERROR discrepancy is generated if the order of the values does not match.

  5. The associations of the matching entities are compared, and an EXTRA_ASSOCIATION or MISSING_ASSOCIATION discrepancy is generated for unmatched target entities of an association. The default relationship handler uses the Name field to match related entities of the compare and reference sides. If an association is an ordered association, an ASSOCIATION_ORDERING_ERROR discrepancy is generated if the order of the matching associated entities is different.

  6. The child relationship of the matching entities is compared, and an EXTRA_ENTITY or MISSING_ENTITY discrepancy is generated for unmatched child entities. The default relationship handler uses the Name field to match child entities of the compare and reference sides. If a child relationship is an ordered association, then an ORDERING_ERROR discrepancy is generated if the order of the matching child entities is different.

  7. The comparison continues by applying the above algorithm to all children entities recursively, until all entities have been checked. The comparison also stops at a given entity if one of the following is true: the entity is a compare root entity, or the entity is flagged as a shadow entity.

The Detect Discrepancy action creates discrepancies with a default severity of CRITICAL for EXTRA_ENTITY and MISSING_ENTITY, and WARNING for the other types.

Adding New Filters and Handlers

This usage pattern builds on the Reuse pattern by adding filters and handlers to customize the general comparison algorithm. The following changes can be achieved:

  • which root discovery entities are of interest

  • how to match discovery entities to import entities

  • which attributes are not significant for a particular entity type

  • how to compare a particular attribute

  • which relationships to consider for a particular entity type

  • what severity to apply to a discrepancy

  • define a relationship as ordered (to automatically add ORDERING checks)

  • set a default/suggested resolution action (e.g. Ignore, Correct in UIM, etc.)

To use this pattern, follow the Reuse pattern to create your detection action, and then create one new detection processor, and move it above the Discrepancy Detector processor in the table. This new processor becomes the Filter Initializer processor for the detection action. (For example, in Figure 11-4, a new action follows this pattern by having its own Sample Filter Initializer processor placed above the imported Discrepancy Detector processor.)

Figure 11-4 Sample Filter Initializer

Shows Sample Filter Initializer

The main task of a Filter Initializer Processor is to register filters and handlers for use by the subsequent Discrepancy Detector processor. Handlers are code that implements various behaviors used during discrepancy detection. Filters are code that manipulates the handlers to be used by discrepancy detection.

About Filters

There are four different types of filters that can be added by the processor:

  • AttributeFilter: This filter is called during the assignment of attribute handlers for the given entity type. This filter can add, modify and remove handlers from the given attributeHandlers.

  • RelationshipFilter: This filter is called during the assignment of relationship handlers for a given entity type. This filter can add, modify and remove handlers from the given relationshipHandlers.

  • DiscrepancyFilter: This filter is called during assignment of discrepancy handlers for a given entity type. This filter can modify or remove the default discrepancyHandler.

  • RootEntityFilter: This filter is called during the assignment of the root entity handler for a given entity type. This filter can replace the default rootEntityHandler with another one.

About Handlers

There are four different types of handlers that can be manipulated by their associated filters:

  • AttributeHandler: This handler can change the mapping of attributes, or change the behavior of the comparison operation. For example, a string comparison is normally case-sensitive. An attributeHandler can be added to cause a case-insensitive comparison to be used instead.

    Network Integrity provides a DefaultAttributeHandler class which implements the necessary AttributeHandler interface and the default case-sensitive string comparison behavior. To override this behavior, create a class which subclasses DefaultAttributeHandler, and then override the following method:

    protected boolean equalsNonNull(Object a1, Object a2);
    
  • RelationshipHandler: This handler can change the mapping of relationships. For example, a relationship comparison would normally check the identically-named relationship on the reference entity. A relationshipHandler can be added which causes a differently-named relationship to be used instead.

    Network Integrity provides a DefaultRelationshipHandler class that implements the necessary RelationshipHandler interface, and has knowledge of all relationships for each supported Oracle Communications Information Model entity type. The following method can be overridden by a new subclass to alter the default behavior.

    protected Object getKey(DiscrepancyEnabled entity)
    

    This method gets a key value that distinguishes a single entity from a set of entities within a single relationship. The DefaultRelationshipHandler implementation returns the value of the Name attribute for the input entity.

  • DiscrepancyHandler: This handler can change the fields of a discrepancy immediately after it is generated. It can also completely remove the discrepancy. An example of its use is to adjust the severity value of a discrepancy of a DeviceInterface entity based on its Speed value.

    Network Integrity provides a non-accessible default DiscrepancyHandler implementation which does nothing. To override this behavior, create a class which implements the DefaultHandler interface, and implement the following method.

    DisDiscrepancy processDiscrepancy(DiscrepancyEnabled currentEntity,
                                      DisDiscrepancy generatedDiscrepancy)
    

    The overridden method should alter the input generatedDiscrepancy, and then return it.

  • RootEntityHandler: This handler changes the algorithm for finding a matching reference entity for an input compare entity. An example of its use is to change the default comparison criteria to using the ID field to find the match, instead of the default of using Name field.

    See Example 4: Using Root Entity Filter and Handler for a full example of the proper setup and usage of a root entity handler.

Filters and CimType

Filters register against one or more types of Information Model entities produced by a Discovery, Import, or Assimilation scan. Filters can also register against one of more Specifications of an entity type, for more fine-grained control.

In Java code, the entity type and specification are designated by using the class CimType. To register a filter against an entity type (for example, Equipment), use the single parameter constructor for CimType:

CimType eqType = new CimType(Equipment.class);

To register a filter against a particular specification (for example, cevSensorClock, an Equipment specification defined in the Cisco UIM cartridge), use the two-parameter constructor for CimType:

CimType clockEqType = new CimType(Equipment.class, "cevSensorClock");

It is possible to take advantage of the inheritance model of the Information Model entity classes to register quickly against several classes with one call. For example, all Information Model entities that support discrepancy detection inherit from the class DiscrepancyEnabled. Therefore, the following code CimType can register a filter against everything:

CimType allType = new CimType(DiscrepancyEnabled.class);

Filter and Handler Examples

The next four examples demonstrate the four types of filters and handlers. The prerequisite tasks for all examples are to:

  1. Create a Discrepancy Detection Action.

  2. Set the Result Source in the Result Source tab.

  3. Add the Detect Discrepancy action in the Processors tab.

  4. Create a filter initializer Processor.

  5. Move the new processor above the Discrepancy Detector processor.

Example 1a: Using Attribute Filter and Handler (Static Attribute)

The following code fragments shows how to add an attribute filter to ignore the static attribute description on LogicalDevices. The result of this code is that the new detection action does not generate any description Attribute Value Change discrepancies on LogicalDevices.

  1. Define the filter class and remove the handler for the attribute description.

    private class LogicalDeviceAttributeFilter implements AttributeFilter {
        public void filterAttributes(
                       CimType cimType,
                       Map<String, AttributeHandler> attributeHandlers) {
            attributeHandlers.remove(”description”);
        }
    }
    
  2. In the processor invoke() method, get the generic discrepancy detector from the context.

    GenericDiscrepancyDetector detector = context.getDiscrepancyDetector();
    
  3. In the invoke() method, create the CIMType object to name the entity type, and add the custom filter.

    CimType ldType = new CimType(LogicalDevice.class);
    detector.addFilter(ldType, new LogicalDeviceAttributeFilter());
    

Example 1b: Using Attribute Filter and Handler (Characteristic)

The following code fragments show how to add an attribute filter to ignore the characteristic systemObjectId on LogicalDevice entities with the specification DemoLogicalDevice. The main difference between this example and the previous example is Step 3, where the Specification name must be included in the CimType constructor.

  1. Define the filter class and remove the handler for the attribute systemObjectId.

    private class DemoLogicalDeviceAttributeFilter implements AttributeFilter {
        public void filterAttributes(
                       CimType cimType,
                       Map<String, AttributeHandler> attributeHandlers) {
            attributeHandlers.remove(”systemObjectId”);
        }
    }
    
  2. In the processor invoke() method, get the generic discrepancy detector from the context.

    GenericDiscrepancyDetector detector = context.getDiscrepancyDetector();
    
  3. In the invoke() method, create the CIMType object to name the entity type and the specification, and add the custom filter.

    CimType ldType = new CimType(LogicalDevice.class, "DemoLogicalDevice");
    detector.addFilter(ldType, new DemoLogicalDeviceAttributeFilter());
    

Example 2: Using Relationship Filter and Handler

In this example, the detection action to skips the physicalPorts relationship of all Equipment entities. By using the following code fragment, the new detection action no longer examines any children ports of equipment.

  1. Define the filter class and remove the relationship handler for the relationship physicalPorts.

    private class EquipmentRelationshipFilter implements RelationshipFilter {
        public void filterRelationships(
                       CimType cimType,
                       Map<String, RelationshipHandler> relationshipHandlers) {
            relationshipHandlers.remove("physicalPorts");
        }
    }
    
  2. In the processor invoke() method, get the generic discrepancy detector from the context.

    GenericDiscrepancyDetector detector = context.getDiscrepancyDetector();
    
  3. In the invoke() method, create the CIMType object to name the entity type, and add the custom filter.

    CimType eqType = new CimType(Equipment.class);
    detector.addFilter(eqType, new EquipmentRelationshipFilter());
    

Example 3: Using Discrepancy Filter and Handler

This example sets the severity to Minor on every Missing Entity and Extra Entity discrepancy generated by the new detection action. Use the following code fragment for this task:

  1. Define the filter class and add a new discrepancy handler. This handler performs a discrepancy type check, and sets the severity accordingly.

    private class CustomDiscrepancyFilter implements DiscrepancyFilter {
        public DiscrepancyHandler filterDiscrepancies(
                       CimType cimType,
                       DiscrepancyHandler handler) {
            return new DiscrepancyHandler() {
               public DisDiscrepancy processDiscrepancy(
                  DiscrepancyEnabled cimBase,
                  DisDiscrepancy disDiscrepancy) {
                     if (DisDiscrepancyType.EXTRA_ENTITY == 
                         disDiscrepancy.getType()
                         || 
                         DisDiscrepancyType.MISSING_ENTITY ==
                         disDiscrepancy.getType()) {
                        disDiscrepancy.setSeverity(DisDiscrepancySeverity.MINOR);
                     }
                     return disDiscrepancy;
                  }
            }; // end return new()
        }
    }
    
  2. In the processor invoke() method, get the generic discrepancy detector from the context.

    GenericDiscrepancyDetector detector = context.getDiscrepancyDetector();
    
  3. In the same invoke() method, create the CIMType object to name the entity type, and add the custom filter.

    CimType allType = new CimType(DiscrepancyEnabled.class);
    detector.addFilter(allType, new CustomDiscrepancyFilter());
    

Example 4: Using Root Entity Filter and Handler

This advanced technique in this example changes the matching algorithm that finds the matching reference entity for any compare entity. The default algorithm finds matches based on a comparison of the value of the name attribute. This example changes the comparison to use the nativeEmsName attribute instead.

Note:

This feature is used in the MIB II UIM cartridge.

The example is in two parts. The first part alters the root entity handler to match compare root entities with reference root entities using the nativeEmsName attribute. The second part use relationship handlers to make the discrepancy detector use nativeEmsName attribute to distinguish the children.

First, the root entity filter and handler code fragments are as follows:

  1. Define a method in the new processor to create the root entity filter. This filter creates a new root entity handler and returns it.

    private RootEntityFilter getRootEntityFilter() {
        return new RootEntityFilter() {
            @Override
            public RootEntityHandler filterRootEntities(
                    CimType arg0, RootEntityHandler arg1) {
                return new MatchRootEntityByNativeEmsNameInsteadOfName();
            }
        };
    }
    
  2. Define a private class that extends from DefaultRootEntityHandler. This class is the one created in step 1. Override the getReferenceRootEntity() method as follows. Notice the use of a string array containing the string nativeEmsName to specify the use of this attribute. Also notice the use of a RuntimeException to report problems.

    private class MatchRootEntityByNativeEmsNameInsteadOfName
            extends DefaultRootEntityHandler {
        @Override
        public DiscrepancyEnabled getReferenceRootEntity(DiscrepancyEnabled compareRoot) {
            try {
                PomsManagerFactory factory = new PomsManagerFactory();
                DisResultGroupManager DisResultGroupManager = 
                    factory.getDisResultGroupManager();
                DisResultGroup g = DisResultGroupManager.getDisResultGroup(
                    (Persistent) compareRoot);
                return new ReferenceRootFinder(g).
                            findReferenceRoot((Persistent) compareRoot,
                                              new String[] { "nativeEmsName" });
            } catch (Exception e) {
                logger.log(Level.SEVERE,
                           "Error while getting reference root, compareRoot " +
                           compareRoot, e);
                throw new RuntimeException(
                    "Error while getting reference root, Aborting discrepancy generation",
                    e);
            }
        }
    }
    
  3. In the invoke() method of the processor, create the CIMType object to cover all entity types, and add the root entity filter defined in step 1.

    CimType allType = new CimType(DiscrepancyEnabled.class);
    context.getRootEntityLoader().addFilter(allType, getRootEntityFilter());
    

Part two adds a relationship filter to each entity type that the detection processor expects to encounter. This code fragment example shows a change to a single entity type. It changes the LogicalDevice to DeviceInterface child relationship to match using nativeEmsName instead of name. Normally, this code pattern needs to be repeated once for each entity type. (See the MIB II UIM and Cisco UIM cartridge packs for a full example.)

  1. Define the relationship handler as a class inside the processor's class. This class should inherit from DefaultRelationshipHandler, and override the getKey() method to return

    public class MatchDevIntfByNativeEmsName extends DefaultRelationshipHandler {
        @Override
        protected Object getKey(DiscrepancyEnabled entity) {
            return ((DeviceInterface) entity).getNativeEmsName();
        }
    }
    
  2. In the processor invoke() method, get the generic discrepancy detector from the context.

    GenericDiscrepancyDetector detector = context.getDiscrepancyDetector();
    
  3. In the same invoke() method, create the CIMType object to name the entity type, and add the custom filter.

    CimType ldType = new CimType(LogicalDevice.class);
    detector.addFilter(ldType, new RelationshipFilter() {
            @Override
            public void filterRelationships(
                    CimType cimType,
                    Map<String, RelationshipHandler> relationshipHandlers) {
                relationshipHandlers.put("deviceInterface",
                                         new MatchDevIntfByNativeEmsName());
            } // end filterRelationships
        } // end new RelationshipFilter
    ); // end addFilter
    

Adding Post-Processors

This usage pattern builds on the Reuse pattern and adds processors after the Discrepancy Detector processor. These post-processors access the full set of detected discrepancies using the getDiscrepancies() method of the DiscrepancyDetectionProcessorContext object (context). Because they are not persisted until all processors in the action have executed, the discrepancies can be manipulated completely by the post-processors. They can be modified or removed. Also, new discrepancies can be added.

Although all fields of a discrepancy can be modified by using setters, there are many fields that should not be altered. The following discrepancy fields can be safely changed by post-processors:

  • priority, notes, discrepancyOwner

  • severity, compareValue, referenceValue

  • operation + operationIdentifiedBy + status (status set to OPERATION_IDENTIFIED) (Must be set together.)

Any other discrepancy fields should not be altered; otherwise, discrepancy resolution actions may suffer errors and failures.

An example of the use of post-processors is to automatically assign all CRITICAL severity discrepancies to a specific department (using the discrepancyOwner field). The following code snippet from a post-processor shows how this is done.

@Override
public void invoke(DiscrepancyDetectionProcessorContext context,
        DiscrepancyPostProcessorProcessorRequest request)
        throws ProcessorException {
    
    for (DisDiscrepancy discrepancy : context.getDiscrepancies()) {
        if (discrepancy.getSeverity().equals(
                DisDiscrepancySeverity.CRITICAL)) {
            discrepancy.setDiscrepancyOwner("Sherlock Holmes");
        }
    }
}