Entities in Policy Automation

One of the funnest parts of the Oracle Policy Automation Training which I regularly deliver are the “Entity” chapters. These chapters (sadly rather short, and positioned right at the end of the week, limiting the time we can spend on them) introduce something that most students have already guessed at long before we get there: There must be more than just creating attributes and writing rules – what happens when I have two members of the same family, or three cars, or five Service Requests….

You can insert any typical Enterprise Software entity model in the end of the phrase above. Since this is such an interesting and sometimes challenging part of the course, I thought we could have some fun looking at entity functions, attributes and so on in a series of posts.

Getting Started

So let’s set the scene : consider the following entity diagram:

OPA Cars Workshops Model Start

We will build it in the next few posts, and then extend and manipulate it in various ways to demonstrate Entity Functions and more.

So starting from scratch, let’s look at a couple of common traps to begin with.

Creating the Entities

Beginning with a new Project and a new Properties File, create two new Entities that are children of the Global Entity.

Common trap 1 : There is, in this model, no need to create a “singleton” Entity for the workshop. Any atttribute that belongs to the “workshop” can be added to the Global Entity.

 

OPA - Car and Mechanic Entities

 

 

Common trap 2 : As soon as you create the Entities, remember to edit the “Containment Relationship” text. If you want to create rules to count or sum mechanics or cars, then you probably want to be writing rules like this :

OPA - Total Number of Cars Long Text

OPA - Total Number of Cars Short Text

 

 

 

But if you go ahead and try it now, the only thing that will work is the following text, or the long version of it. The problem is the default Containment Relationshop text is something like “All instances of XXX” (where XXX is the Entity name).

OPA - Total Number of Cars with Containment Relationship Text Demonstration

 

 

So you would in this case be advised to change the Containment Relationship Text from the default as shown above, to something a little more friendly.

OPA - Containment Relationship Text Edited

 

 

Doing this right now has many advantages, not least readability, but also avoiding common build errors such as “Entity XXX is defined twice”.

If you are writing your Rulebase and rules in another language, watch out for more of the same. For example, the same Entities built in French would give us the following basic grammatical error in the standard Containment Relationship text:

 

OPA - Entity Model French Grammar

“Toutes les instances du mécanicien” would at least be grammatically correct, although as in English this would be unfriendly for business users. So we would change the Containment Relationship text to “toutes les voitures” and “tous les mécaniciens” –  then we could write the following rule without hindrance.

OPA - French Rule with Containment Relationship Text Edited Short Version

 

 

Common trap 3 – Never assume that in two different languages, the syntax will be correctly shown in the Function Reference. A close look in the French Function Reference gives us two versions of the InstanceCount, one long and one short, as is often the case:

OPA - Error in Function Reference FR and EN

 

 

For the purposes of comparison I have put the English and French side by side. There is an error in the French Function Reference mentioning that the Entity (ent) is the required input argument for the function, when in fact it is the Relationship Text (relationship) that is required, as correctly stated in the English version.

In the next post we will continue to work with our Entities and add some attributes and rules to the mix. Until next time.

Entities Adventures 1