Skip navigation

today = the current date


Consider that OPA conclusion above (or in some projects the equivalent: the date of assessment = the current date)


First, I don't mind the form the conclusion takes.  However, that single important rule MUST exist in every OPA project I evaluate.  Further, the current date may only show up once in every project I evaluate (and it must be in this context).  Everywhere else, I want to see today or the date of assessment.


Second, and this is not so evident, my test cases always contain a baseline that overrides today to some known date with a known set of results.


Third, and I will elaborate on this later, I don't delete policy and associated test cases until the information that was determined by the policy no longer has value.



This rule enables policy to be invoked ... as of XXXX-XX-XX.  Policy can be invoked in the past, present, or future.  By leaving the attribute alone, determination is done in the present.  By overriding the intermediate attribute today or the date of assessment, the policy can be invoked in the past or the future (assuming future policy has been put into the project.)


This rule enables interesting ability to correct policy and have impact analysis on the incorrect policy.  (One of my next blogs will elaborate on this.)


This rule, in some instances, even allows future rules to be put into production and tested in a production context.  (Again, I will elaborate.)


This rule begins a discussion of what I refer to as the change in observer's perspective.



It has been about 10 years since I took formal OPA training.  I know Oracle mentioned this concept in that training way back then, and I believe Oracle mentions this in several PDF guides.  I assume Oracle still agrees.  A lot has changed in 10 years (for instance, temporal reasoning was introduced afterwards - I believe in 10.2 or 10.4????  Going down memory lane.)  Let's see what cool/advanced things we can do with this today.

Let me start with disclaimers:

  • I am NOT employed or otherwise compensated by Oracle, so please do not hold Oracle accountable for the content on this blog. 
  • I don't claim these methods shown are the only methods or even the best methods to tackle some of these problems.
  • As Oracle adds functionality, some of the techniques described may be deprecated.


Over the next few blog posts and weeks, I would like to provoke thought on a few questions such as:


  • Is there a technique for retroactively fixing rates or other policy errors in OPA?
  • Why would anyone put undecided policy into OPA, let alone production?
  • Is there any guidance on when OPA policy rules should be removed after they have been used in production?
  • Is there any guidance for which OPA policy rules should have effective and/or expired dates?
  • ...and so on.


Today, some background from me...


I will not rehash what Oracle has already provided in help documentation.  Please review the OPA documentation on Dates and Temporal reasoning.


Background: What "changes over time" are important to me in these blog discussions?


Oracle mentions three (3) changes over time, specifically they are mentioned when deciding if temporal reasoning is needed:

  1. Changes in policy and rules.
  2. Changes in rates and other reference data.
  3. Changes in circumstance.


I might argue that "changes in policy and rules" also includes "changes in rates and other reference data".   I argue they are the same thing, but arguing that point is academic at best.  Who cares?


Instead, I want to discuss a 4th type of change over time: "4. Changes in the observer's perspective."


If I execute a rule last week, vs this week, vs next week, the result can change ( I refer to when the rule was executed as the observer's perspective.)  Results changing seems obvious if the policy and circumstance change between last week and this week.


BUT, I can run a rule last week with all the same circumstance and no organizational policy change and still come up with a different answer.  That is not so obvious.


One Example:


Last week we calculated a benefit with an incorrectly written policy rate.  Since then, somebody fixed the rate retroactively to beginning of fiscal year.  Now we calculate the same benefit, for the same time-frame and effective date but we get a different result from before it was fixed.


Surely, nobody can simplistically write rules which take into account observer's perspective for that scenario?  Actually, yes, we can :-)  I have rulesets that can run the rules as they were observed in the past so that I can determine impact of a past incorrect rate against the present.  This is done by having rules that maintain the observer's perspective.  It is very useful in impact analysis.  The point is "observer's perspective" as a 4th change over time...

Background #2: Natural language vs functions on this blog


There is occasionally debate over whether it is better to use a natural language syntax vs a function syntax in policy writing.  In other words, do you use "the greater of <x> and <y>" or "Maximum(x,y)"?


Generally, I use the following guidance and ask staff to do the same (there are always exceptions):


1) Write rules in the language of the original source material.

2) Write rules for others.  Write rules in a natural language that will be understood by Policy Analysis and by users who read the decision reports.

3) Math formulas can be written in a more succinct functional syntax, but it should look like math.


For reasons unknown to me, but probably pretty good reasons, temporal reasoning functions don't have a natural language equivalent.  There is no "maximum of <attribute> in the interval of <start date> to <end date>" equivalent of "IntervalMaximum(<start date>,<end date>,<attribute>)"


In those cases, my rule #4 is to "access the temporal timeline" using natural language as long as performance allows.  I can provide a future blog on that and performance implications.



Don't impress others with the complexity you can handle.  Impress others with the simplicity that you can provide.

Have you ever upgraded an older 10.x version of an OPA project to 12.x, only to find out that the Microsoft Word menu looks like this?


Oracle Policy Automation menu is missing text.  The menu only has icons.  Well, there is a trick to correcting it.


Somehow, the project itself is messed up, so the project needs to be corrected.


The simplest way I have found is as follows:

  1. add the project to repository,
  2. open the project fresh from the hub
  3. create a new working copy...


That seems to fix this issue.




After this post was put up, more attention was paid to the issue.  It now appears that the root cause has to do with usage of OneDrive.  Perhaps a trust issue.  Although we are not exactly sure the issue, the reason the above process worked is because it essentially created a new copy of the project locally, instead of on OneDrive.