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:
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.