Intermediate Oracle Policy Automation – OPA Ordering Pattern

 

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 the "OPA Ordering Pattern" used when OPA must provide the best ordering among many possibilities.

 

Intent

  • Provide ordering (or sorting or ranking or sequencing) of entities based on rules.

 

Problem

You need to support selection of entities where more than one entity can suffice. A score system or other form of rules that are based on preferences is desired.

 

Discussion

This pattern was discussed (although not named) in an Oracle Tutorial "Tutorial – Limits, Thresholds and Preferences in OPM (Nov 2012)" as well as the Oracle Forums and even student courses and handbook.  The problem of ordering is a common one.

In the tutorial, Oracle laid out the basic pattern.  The implementation has gotten more advanced since the introduction of the concept, but the pattern is the same.

First, isolate your choices as an entity.

Second, infer the range of the alternative choices from all the choices via a self-relationship.

Third, infer a refinement of the choices if necessary with a separate rule.

Finally, repeat the third step in iterations until the choices are refined satisfactorily.

Historically, multiple relationships were created to refine the range of the choices.

 

In the Tutorial from Oracle, there were three (3) relationships created as follows:

1)    An entity self-relationship for alternative choices.

2)    An entity self-relationship for preferred choices.

3)    An entity self-relationship for next more preferred choices.

However, in more recent versions of OPA the refining of information about combinations of entities is better provided through "data sharing between entities."  As applied in this pattern, this newer method or refinement is conceptually an entity self-relationship with attributes attached to it.

See Example 4B of the OPA documentation.

 

 

 

Structure

The structure adds three (3) necessary components to a project:

1)    An entity to be ordered.

2)    At least one self-relationship defined for the entity.

3)    A method of iterative refinement of groupings (either many self-relationships, or a more modern relationship entity).

 

Example

See the attached example which shows two methods...

The first is the simplest sorting example and uses the following:

 

Source

Target

Type

Text

Reverse Text

Identifying Attribute

Global

the choice

Containment

all of the choices

 

the choice

the choice

the choice

Many to Many

the next choice

the prior choice

 

 

"the choice" is the entity to be ordered.

"the next choice" is the self-relationship based on a score in each entity.

That is it. Based on the above rule, the choices are sorted by score.

The second example performs multiple refinements and uses the following:

 

Source

Target

Type

Text

Reverse Text

Identifying Attribute

Global

the choice

Containment

all of the choices

 

the choice

the choice

the alternative

Containment

the choice's alternatives

 

the alternative

the alternative

the choice

Many to One

the alternative's other choice

 

 

 

"the choice" is the entity to be ordered.

"the alternative" is the self-relationship entity containing properties of refinement for narrower groupings.

The Oracle tutorial first rule finds alternative choices.  It uses a self-relationship of "the inventoried item's alternative sources". The rule has been copied here for reference:

That rule is abstractly represented in this modern example, by inferring a self-relationship entity as follows:

And since we have inferred a new entity, it is a good idea to give the entity an identity as such:

the alternative = the choice  + “’s relationship to “ + the alternative's other choice

the alternative's other choice = in the case of the alternative's other choice, the choice

 

The next refinement rule in the Oracle tutorial is used to provide preference shown here:

In the more modern example, we use "the choice score" instead of the price. "the choice score" can be any logic that can rank one choice above another choice such as the logic on price.  BUT, and this is where the additional modern OPA power comes into play.  User input / selection in interviews can also be used.  We demonstrate that with "the user's additional score for the alternative".

So this example refinement allows user refinement.

And a final refinement in the Oracle tutorial looks as such:

In this example, we allow users to add their preferences through the interviews.  If the user preferences in the interview are higher, we use those, otherwise we use regular scores…  So, we put in lots of refinement possibilities.

 

At this point, the example stops refining, although any grouping may be provided via the self-relationship entity.

 

Check list

1) An entity for selection and comparison.

2) An entity self-relationship.

3) Multiple rules that build on each other to refine the choices.

 

Rules of thumb

  • It is generally a good idea to provide reverse text for all relationships, but it is not required for this pattern.
  • It is common practice and a good idea to provide a 1:1 relationship to the first entity, although that is not required for this pattern.

 

Opinions

This pattern solves one of the most recurring questions on the OPA forums.

BTW, for the first simple example on ordering, the "first" choice can be easily found with the simple rule: