Skip navigation

Advanced Oracle Policy Automation – OPA Access Timeline Pattern

Disclaimer: There will be advanced concepts that require the reader to have a firm foundation in OPA.

OPA patterns show up over and over to solve problems such as the need for the shortest interviews, need for wizards, and need for calculators. In this blog post I will discuss what I refer to as my "OPA Access Timeline Pattern" used when temporal functions get in the way of substantive policy readability.

Intent

  • Allow temporal attributes to be specified using natural language in substantive rules.

 

Problem

Temporal reasoning often seems complex to the uninitiated. It is the type of logic that grows very rusty with lack of use. Natural language, on the other hand is used in our day to day conversations. Natural language policy has many advantages over temporal functions such as being understood by the uninitiated.

We need a more natural form of temporal reasoning that uses the natural language advantages of Oracle Policy Modeling.

 

Discussion

There is a method of creating many attributes temporally in substantive rules without referring to temporal functions. It is a technique known as accessing the temporal timeline. It can greatly reduce temporal function usage and increase readability of rules that rely on temporal logic.

The concept is quite simple. A date attribute is created that contains a change point every day from an earliest start date to a latest end date. In many cases, instead of using temporal functions, rules compare against this temporal date attribute using a natural language syntax.

There is an Oracle Forum Thread from a few years ago that describes this technique along with feedback from users in the community:

https://community.oracle.com/message/10987706#10987706

 

Structure

The structure adds two necessary components to a project:

1)    Definition of the calendar date attribute such as:

the calendar date = AddDays(the global start date, TemporalDaysSince(the global start date, AddDays(the global end date,1)))

 

2)    Rules that utilize the calendar date attribute such as:

the person's age = the number of whole years which the calendar date is after the person birth date

 

Example

Attached is a project that demonstrates three methods of working with dates.

The first method uses traditional non-temporal logic (putting the word "standard" in each attribute name) such as:

 

The second method uses this OPA Access Timeline pattern (putting the word "daily" in each attribute name) such as:

 

The third method uses temporal functions(putting the word "computed" in each attribute name)  such as:

Spreadsheets of holidays are included to demonstrate temporal logic differences in Excel.

 

Check list

1)    Outside of the substantive rule document, create a calendar attribute.

2)    Use the calendar attribute in natural language.

 

Rules of thumb

  • This pattern is most effective when dates are being compared or otherwise manipulated in OPA.

 

Opinions

Be careful, as too much use of this pattern can cause OPA to perform very slowly. Be judicious with temporal functions. Everything is an engineering tradeoff. In this case, the primary tradeoff is readability (and simplicity) vs performance.

  The OPA development team has "under consideration" methods to provide natural language equivalents of temporal values. There have been several suggestions. However, Oracle is concerned that any added temporal natural-language feature may break existing natural language projects that are not temporal-based. 

Advanced Oracle Policy Automation – OPA Rule Revision Pattern

Disclaimer: There will be advanced concepts that require the reader to have a firm foundation in OPA.

 

OPA patterns show up over and over to solve problems such as the need for the shortest interviews, need for wizards, and need for calculators. In this blog post I will discuss what I refer to as my "OPA Rule Revision Pattern" used when a rule change may impact existing determinations.

 

Intent

  • Allow a rule to have an effective date.
  • Take into account the date the rule is deployed.
  • Be able to change "the current date" to select rules based on when they should be invoked.
  • Allow a project to be deployed with "future rules" and test in production before the rules go into effect for production users.

 

Problem

This pattern addresses several needs.

  • A court, a rate mistake, or other event requires a retroactive change in a rule. After the change, users want to compare prior and current determinations.
  • Operations staff do not want to stay up late at night deploying a project with new rules. It would be beneficial to freely deploy rules at any point in time prior to their effective date.
  • For quality control, users want to test rules in the production environment with production data prior to the rules going into effect.
  • A general pattern that is understood by all needs to be set for adding new rules..

 

Discussion

There is more than one important date that impacts when a policy rule comes into effect beyond what is described in the Oracle documentation.

Oracle Documentation - Set the date a rule comes into effect

The additional date is the actual date on (or closely after) which the policy is deployed via "deploy snapshot."

If you have not actually deployed the policy, the policy isn't in effect: a rule that is not deployed never executes.

Recommendation: any rule / rate added to a project which may apply to determinations already made should be compared to the current date for execution. Any rule that is "overridden" by a new rule should also be compared to the current date for execution. Don't delete old rules by default.  Both rules should be mutually exclusive.

What needs to happen is three-fold:

  • First, the current date needs to be overridden such as today = the current date or the assessment date = the current date. Every future policy need for the current date should instead reference today or the assessment date such as "thirty days in the future = AddDays(today, 30)" instead of "thirty days in the future = AddDays(the current date, 30)".
  • Second, rules need to made temporal per Oracle's help documentation.
  • Third, rules need to be given a hard-coded deployment date and compared to the overridden value of the current date from step 1. For example, today >= "2017-01-01" or the assessment date >= "2017-01-01". This may be subtle to new users of rules but a rule can't possibly be utilized prior to it being deployed, even if the effective date is prior to the deploy date.

By hard-coding deployment dates on rules, users can go back (or forward) in time to see how rules impacted determination. This is extremely useful for testing and for seeing if mistakes impacted a client. In future blog posts I will give an example where some clients were accidentally made eligible for a benefit. After the rule was corrected, the business was interested only in clients that were impacted by the corrected rule.

With this pattern, the business now has several options. The business can run the rules at different dates and compare the results. The business can also use the OPA Context Pattern and OPA can set a status field. There are other solutions.

Properly following this pattern allows projects to be deployed early. It allows future maintainers to see a change log of rules in the rules themselves. It allows the business to be able to reproduce results with the base attributes which can have certain future audit benefits such as not needing to store full audit reports with the determined data.

 

Structure

The structure adds three necessary components to a project:

1)    Override "the current date".

2)    Add temporal and deployment conditions to the new and any overridden rules.

3)    Alter test cases to specify the current date.

 

Example

Yearly rate table changes setup in Excel are a common example.

 

In this table below, each sheet has a yearly rate table.  Note that the original rates for 2017 were incorrect starting on 1/1/2017.  A new sheet was deployed with retroactive corrected rates on 2/1/2017.

This is the temporal time being evaluated.  It changes yearly.

2017-02-01 was the deployment date

 

the assessment date

Apply Sheet

TemporalOnorAfter("2011-01-01")

TemporalBefore("2012-01-01")

 

2011

TemporalOnorAfter("2012-01-01")

TemporalBefore("2013-01-01")

 

2012

TemporalOnorAfter("2013-01-01")

TemporalBefore("2014-01-01")

 

2013

TemporalOnorAfter("2014-01-01")

TemporalBefore("2015-01-01")

 

2014

TemporalOnorAfter("2015-01-01")

TemporalBefore("2016-01-01")

 

2015

TemporalOnorAfter("2016-01-01")

TemporalBefore("2017-01-01")

 

2016

TemporalOnorAfter("2017-01-01")

TemporalBefore("2018-01-01")

< 2017-02-01

2017

TemporalOnorAfter("2017-01-01")

TemporalBefore("2018-01-01")

>= 2017-02-01

2017 v2

TemporalOnorAfter("2018-01-01")

TemporalBefore("2019-01-01")

 

2018

 

Check list

1)    Override the current date - the current date should be specified only once in a project as a condition statement when being assigned to the conclusion. Provide a means to override the current date by users / testers.

2)    Provide new rules with both the temporal specification and on or after the deployment date.

3)    Legacy rules also require both the temporal specification and before the deployment date. Legacy and new rules should never overlap and there should not be a gap in time.

 

Rules of thumb

  • Keep test cases with the current date overridden. These test cases should always be valid without alteration.
  • This pattern is needed primarily for adding new rules. Rules that exist from the beginning of a project would only be cluttered with temporal entry points and by specifying when they were deployed.
  • Rules for which no derived data exists don't need to remain in a project.

 

Opinions

The value of this pattern with regression test cases can't be overstated. Every test case should override the assessment date and should be valid until the test case itself doesn't make sense in the very far future.

This pattern provides valuable insight on past, present, and future rule impact used in conjunction with production data. It becomes a trivial exercise to set up batch jobs that run production extracts of data through the rules and collects the output for analysis at different points in time. This is a far more accurate method of judging impact than traditional warehouse methods.

Rather than being "clutter" these additional conditions on new rules provide insight to the rule history.

There is little to no performance impact.

Advanced Oracle Policy Automation – OPA Warehouse Pattern

Disclaimer: There will be advanced concepts that require the reader to have a firm foundation in OPA.

OPA patterns show up over and over to solve problems such as the need for the shortest interviews, need for wizards, and need for calculators. In this blog post I will discuss what I refer to as my "OPA Warehouse Pattern" used when time-based complexity is very high.

Intent

  • Allow source systems to store events as transactional records
  • Convert transactional events to temporal attributes to manage complexity
  • Simplistically provide all new and historical data for determinations
  • Determinations should be able to aggregate many transactions into single attributes

 

Problem

You need to support policies and data that have lots of changes. The changes produce ever-growing complexity.

To handle all the changes and their impact, constant scoping of transactional entities for use in rules complicates substantive rule documents.

 

Discussion

Design a rule model that makes temporal/entity conversions a “first-class citizen”.

Make a clear delineation between data that can change and data that cannot change over time.

Data that can change over time is provided in fact entities and converted into temporal values for substantive rule processing.

Data that cannot change (for example, the date an application was received, the days of the week, or the person's birth date) is put into Global, or provided in value lists, or put into entities that map to source system entities that have no concept of change.

Relationships are created for the fact entities that will be used to filter and summarize the facts into temporal variables.

The subsequent OPA model tends to mimic a “data warehouse”. Thus, the name I give it.

 

Structure

The structure adds two necessary components to a project:

  1. Temporal Conversion Rule Documents
    1. Contain relationships to event tables. For example:
    2. Contain rules to convert temporal attributes to and from entities. For example:

2)    Temporal Support (Interpretive) Rule Documents. These contain time/date supporting attributes (as opposed to substantive rules). For example:

 

Example

A case status is used as part of eligibility determination. The case status can change retroactively if a change in circumstance occurs. This can impact determination and the monetary balances. Per the examples in the structure section above, the historical case status transactions are provided by the case management system. Convert the case status transactions into a temporal attribute and use that attribute in the rules such as:

 

From transaction records:

Test Cases

the event id

the event start date

the event end date

the event amount

the event record date

the event type

the event status

the event case notes

all

2

1/15/2016

 

 

1/15/2016

status

active

Case made active by worker

all

11

6/10/2016

 

 

6/10/2016

status

inactive

Client disenrolls

all

14

11/10/2016

 

 

11/10/2016

status

active

Client comes back.

all

15

11/10/2016

 

 

12/1/2016

status

on-hold

Recoupment now full

all

19

2/1/2017

2/1/2017

45

2/1/2017

status

active

Let's make an incorrect payment due to bad rule

 

Created as fact entities:

Converted to temporal attributes:

For usage in substantive documents:

 

This greatly reduces complexity as compared to scoping a fact entity and performing date comparisons against that fact entity for every context in which some factor such as case status is needed. More than a rules engine or other approaches to automation, this historical case status to temporal attribute conversion gives your projects a fighting chance to tackle very complex time-based logic.

 

Check list

1)    Identify in the source policy or systems the attributes that can vary over time, such as account balances, assets, status, etc.

2)    If data is used as input attributes to OPA, store the data in the source system for future determinations.

3)    Define temporal conversion rules separate from substantive rules.

4)    Define temporal helper attributes.

5)    Use temporal attributes in the substantive documents.

 

Rules of thumb

  • Persistence in and out of OPA is via transaction-oriented entities.
  • Rules in OPA utilize temporal values.

 

Opinions

One complaint with this pattern is that it occasionally requires temporal functions to be exposed in substantive logic. Most policy staff can’t modify rules with temporal functions.