EventListener Interfaces

EventListener Interfaces

There are three EventListener interfaces: the DecisionReportFilter, Inferencing Listener and AttributeChangeListener.

 

For a description of the DecisionReportFilter, see:

Decision Report Filter

The DecisionReportFilter interface

Installing a DecisionReportFilter

Example: Hide eligibility criteria from a decision report depending on benefit applied for

 

For a description of the InferencingListener, see:

Customize the inferencing cycle with custom functions and inferencing listeners

 

The AttributeChangeListener is for advanced usage and should not be implemented in a production rulebase. More information can be found in the Determinations Engine API.

 

Decision Report Filter

Decision report filters are custom classes (Java or C#) that are authored by a software engineer to filter a decision report using "silent" and "invisible". They are useful when the out-of-the-box decision report options in Oracle Policy Modeling ("silent if true", "silent if uncertain" and so on) are insufficient.

For example considering the following rule determines eligibility for two separate benefits and allows a user-choice as to which benefit is being assessed:

 

the applicant is eligible if

    both

        the applicant is applying for benefit A and
        the applicant meets the criteria for benefit A

    or

        both the applicant is applying for benefit B and
        the applicant meets the criteria for benefit B

 

With this rule, if the applicant does not meet the criteria for either benefit, then both sets of criteria are considered relevant and included in a decision report, regardless of which benefit the applicant was actually applying for. This is correct logically (both are false values that led to a false conclusion) but probably confusing to an end-user who expects to see only the criteria for the benefit they have chosen to apply for.

With a decision report filter, the criteria for each benefit can be hidden conditionally, based on the selected benefit.

The DecisionReportFilter interface

This interface consists of two methods: getAttributeFilter and getRelationshipFilter which are used to add additional silent and invisible flags to a particular attribute or relationship in a decision report. When generating a decision report, the engine will invoke one of these methods for every attribute instance or relationship instance that appears in the decision report. The return value (an object of type DecisionReportFilterResult) determines what additional flags will be applied. The most common options will be DecisionReportFilterResult.SILENT_INVISIBLE and DecisionReportFilterResult.UNFILTERED.

 

Note that if the engine has already decided to make the attribute/relationship silent or invisible (because they are flagged as such in Oracle Policy Modeling), then the decision report filter cannot remove that property. For example a return value of DecisionReportFilterResult.SILENT will make the decision report entry 'silent' but will not affect its 'invisible' status.

Installing a DecisionReportFilter

DecisionReportFilter objects are attached to a Session object in the determinations engine with the Session.setDecisionReportFilter method, and will then apply to every decision report requested from that session. Every session can share the same DecisionReportFilter object if necessary, which is recommended, to ensure efficiency and consistency of behaviour. It is recommended that a decision report filter have no mutable state after being initialised, as multiple sessions could invoke the listener at the same time. At the very least, the object must be thread-safe.

A RulebaseListener (see the topic Rulebase Listeners) is the simplest way to ensure the DecisionReportFilter is automatically set after the session is created, and also provides a place to do one-time initialization of the filter when the rulebase is first loaded.