Tag: Rules

Back to Basics Fun with Relationships

Back to Basics Fun with Relationships

The other day I had cause to discuss Relationships with an Oracle Policy Automation developer, and as a result of the discussions and the level of interest expressed in the learning curve, I thought I would share here the project that I used to illustrate some of the main concepts used when working with them in an Interview. Firstly, to put Back to Basics Fun with Relationships in context, here are the entities we will discuss :

  • Global (of course)
  • the car
  • the passenger

The entities are in part received from another system, and look like this:

To simulate the external system in this demonstration, the data for the cars is coming from a Microsoft Excel spreadsheet which infers various vehicles. The passengers are manually entered in the Interview and then different relationships are using to construct the connections between the cars and the passengers. In this case, we need to identify the passengers in each car (which has been called the car’s passengers here), and then to specify which passenger is sitting in the front seat (which has been called the copilot here). So the car entity has the following reference relationships, both of them with the passenger but of different cardinality.

Back to Basics Fun with Relationships 3

When we look at the first two Screens there is not much to report. The first displays the cars and the second gets the passengers.

Back to Basics Fun with Relationships Cars Back to Basics Fun with Relationships Passengers

The third Screen is where some students can go wrong. The key is to display the relationship (the car’s passengers) . In the case shown, a label has been added to display the car name. Notice how the choice of display is limited to Checkbox because of the cardinality of the relationship. This makes for a situation where the user can choose the passengers and of course a passenger can only be in one car. Selecting the same passenger for two cars produces an error (as it should, even if the error message is generic).

Back to Basics Fun with Relationships Choose Passengers

  1. The relationship is added to the Screen
  2. The selection control is displayed
  3. Only Checkbox is available

The Screen looks like this in the Debugger:

Back to Basics Fun with Relationships Selecting Passengers for Cars

Finally, the fourth Screen will allow the selection of one of the passengers to be assigned as the front seat passenger (a.k.a the copilot). The Screen is displayed below and the key areas highlighted:

  1. Again we add the relationship to the Screen
  2. The cardinality means the default display option is a Drop-down, although others are available in the Toolbar this time (fixed list or radio buttons). I wish these were customizable using Control Extensions but they are not…as of 18A.
  3. The display will allow you to select a copilot, and filtering the data ensures that only passengers of the correct car are available. In this way, the first relationship (the car’s passengers) drives the second (the copilot).

The Screen looks like this in the Debugger:

Back to Basics Fun with Relationships Copilot

Finally there was a requirement to associate the copilot with the car in a more direct fashion. Specifically, the car entity had attributes to contain the name of the copilot. The basics (not complete) of this are shown below:

Back to Basics Fun with Relationships Mapping

So the car has a front seat occupant boolean attribute and the value is retrieved from the passenger entity and the copilot relationship and copied into the car attribute. The relationships and the entities allow us to retrieve data in the structure and place it in the car.

Back to Basics Fun with Relationships Data Tab

Hopefully this example will let you imagine how relationships can be used to enhance your Oracle Policy Modelling. I hope you enjoyed this Back to Basics Fun with Relationships post. As always the official Oracle Policy Automation documentation can be found here.

Rule Design – How Far Do You Go?

Rule Design – How Far Do You Go?

The topic of genericization in rule design came up the other day. I should explain first what was meant, and the easiest way to do that is with an example.

Suppose an OPA Customer conceives a rule that looks a little bit like this

Rule Design OPA 12Some time later, the same customer finds that there are several similar rules, such as the next one below.

An attempt is made to streamline the rules into a more appropriate structure first of all. So a rule might be rewritten to take into account not just a boolean conclusion but something more interesting, such as return codes.

Rule Design OPA 12Shortly after that, as the realization dawns that there are thousands of rules like this, a further effort occurs to streamline the concept even further as shown in the example below.

Rule Design OPA 12Here we can see the rules are broken down in the manner of with input arguments that may be numbers, Booleans and so on. The exact components of each validation are detailed. This is further extended and generalized, broken across Excel and Word (to cope with grouping operators like either) and what have you.

And so the usage of the validations becomes something a little like this (I am exaggerating for effect). Further tables are created to schematize which rules are used in which business context. We shorten the attribute names, create legends, standardize the text used.

Rule Design OPA 12

We are so far away from anything resembling natural language that we might as well be using the Microsoft Win32 API. We have delivered our Rule Design but have we best served the customer? Of course the context is key (the audience for the rule design documents, the purpose of the rules – Web Service or Interview, to mention only a couple of criteria) but the presence of different teams and different competing teams – internal or external – seems to lead to black box designs that only serve to frustrate the customer.

Back to Basics 4 – Levels in Oracle Policy Modeler

 Back to Basics 4 – Levels in Oracle Policy Modeler

One of the things that students struggle with in the Oracle Policy Automation Essentials class which was offered by Oracle University for OPA version 10, but never upgraded to version 12 (something which I struggle to understand, and I will freely admit so do the customers I meet, to the point where I am obliged to deliver version 12 Essentials using custom environments and complicated workarounds from an administrative perspective) is the concept of Levels in Oracle Policy Modeler in writing rules.

Perhaps the term “levels” is the problem. Anyway, here we go

Basic Idea #4 – Rules written in Word can express logic in a hierarchical fashion, for example

Levels in Oracle Policy Modeler

If it helps get a grip on this hierarchical layout, consider the following alternative :

Levels in Oracle Policy Modeler Alternative

In both cases the structure of the rule is hierarchical, in the second case each subordinate conclusion is presented separately. In the first instance they are all included in the first premise, as nested levels. Notice the “OR” in the first example, and how it is yellow in color, because it relates to the comparison between the two yellow components – more correctly, it compares two level one conditions, which themselves have level two conditions. It is a common issue for beginners to misplace the “OR” or to color it with the wrong level of nesting.

There are upsides and downsides to both approaches, and there are plenty of other criteria (mapping to source documentation, readability, ease of location and display in interviews to name just a few) that may drive how you write these nested structures. But as a new starter, considering that Levels in Oracle Policy Modeler show the proof needed to prove the higher level, can provide an easy to remember way to correctly nest your Word text in your Rule Projects in Oracle Policy Modeler.

Have a nice day.

Logo by Southpaw Projects LLC