Rule loops in OPA rules

Rob Bradford | OPA Rules Consultant (Europe)

As any experienced rule author will know, OPA automatically runs through a series of logic checks each time a policy model is built. One of these checks is for self-referential rules, or to put it another way rules that are proven by themselves – the logical loop check. In rare situations, usually when writing complex rules involving time based reasoning or multiple entity instances, it may be necessary to implement a controlled logic looping situation.

First introduced in OPA version 10.2, rule loops allow you to overcome the problem of rules which loop back to different instances in the same entity by defining a rule as an allowable loop, allowing the rules to validate past the logical loop check.

Loops using entity instances

The following fictitious example shows an example of a 'valid' rules loop using different entity instances. The source material states:

"a person can be a UK passport holder if they meet the qualifying criteria, or if any of their parents are eligible for a UK passport."

The rules highlighted in the red boxes below cause a logical loop upon build, however in this case the logic is correct.

To implement a rule loop in OPM, first highlight the rule. Then use the Rule Properties Editor (ALT + P) in the Word toolbar, and tick the Rule Loop checkbox:

The policy model now passes validation, and is logically sound. In the following interview, Tom has been identified as Sarah's parent. Tom has been in the UK for 30 years with no criminal record, therefore qualifies. Even though Sarah does not qualify on her own accord due to the length of time spent in the UK, the fact that she has a qualifying parent means she also qualifies.

The decision report within Oracle Web Determinations shows that Sarah qualifies on the basis of her parent, Tom:

You may have realised that the way these rules have been written, even if Tom was not suitable, he may himself have a parent who qualifies - which would make Tom, and therefore Sarah eligible. Following this sequence through, it would mean anyone with a qualifying ancestor would automatically be eligible themselves.

In this example we can assume this is the intended behaviour - but it is essential to consider where the loop could, and should end. This is sometimes referred to as identifying the exit condition.

Loops using temporal reasoning

Loops can also relate to an attribute's value at different points in time, rather than different entity instances. Consider the following logic:

"An applicant will be treated as qualifying for the benefit continuously if they have been out of the country for less than 7 days, and at the time they left the country, they qualified for the benefit"

Again, we are looking at a different instance (this time on the temporal timeline) of the attribute, but OPA will identify 'the applicant qualifies for the benefit' as a loop. Specifying the attribute as a rule loop, using the method shown above can allow the rules author to overcome this.

Consider the following worked example:

  • John's benefit period runs from 1 Jan to 31 Jan 2014 (all dates inclusive). He satisfied the income criteria to qualify for the benefit throughout the month, apart from one period between 18 Jan and 20 Jan, where his income was too high.
  • John was out of the country from 6 Jan to 16 Jan - a total of 11 days. As he continued to meet the income criteria, and qualified for the benefit the day before he left, he was entitled continuously for the first 7 days of his absence.
  • On 13 Jan, John had been out the country for more than 7 days, so became ineligible.
  • When John returned to the country on 16 Jan, he became eligible again - until 18 Jan when he did not satisfy the income criteria.
  • On 19 Jan, John left the country again until 23 Jan. Although the absence was less than 7 days, and he met the income criteria from 20 Jan, he was ineligible throughout the entire absence because he was not eligible the day before he left.
  • When he returned to the UK on 23 Jan, he became eligible again. In total, he was eligible for the benefit for 23 days out of the 31 day period.

Final points

  • Careful consideration should be given before implementing rule loops, as incorrect use can result in rules that can never be proven. If you are not sure, ask an OCS consultant.
  • The logical loop check is there for a reason! You should only use this feature if you are sure there is an exit condition. If the loop is not controlled, then the OPA rules engine will keep going around and around until it eventually stops with an error.
  • It is very important that the rules are tested thoroughly to avoid any unexpected behaviour.
  • If the loop encompasses multiple rules, each individual rule must be configured separately.

This blog is brought to you by Oracle Consulting Services. Further details about OPA enablement, coaching and mentoring services can be obtained by contacting the author.


Post a Comment:
Comments are closed for this entry.

Welcome to the OPA blog where Oracle's Policy Automation experts share their views on everything OPA.


« November 2015