OPA – Entities Adventures #5 Entity Functions…

Entity Functions

Moving forward in our investigation of the Oracle Policy Modelling and the Entities we have created, we can now begin to leverage some of the common Entity Functions. Consider the following requirements

For each car in the garage, indicate if it is

  • Being worked on
  • Requires parts to be ordered

At the same time, indicate the profit expected from each vehicle. Based on this figure

  • Indicate cars worth repairing, for each mechanic

How can we decide if a vehicle is being worked on? In the Policy Automation class which I teach very often, we create an Attribute “the car is being worked on” (Boolean). In the example in this post, we will use another method which may or may not be appropriate for your business requirement.

First let us consider the nature of the relationship. Each car can have 0 or 1 mechanic. A mechanic can have many cars. So our first attempt might be using the Exists function, which can detect at least one of a specific Relationship, and can apply one condition.

OPA - Entity Exists

The initial result is promising since with populated data and Relationships known, the Debugger displays:

OPA - Car Entity Being Worked On

The downsides are that the Attribute value will be “Unknown” if the Relationship is unknown, which can confuse the User. Observe the Debugger showing the result below.

OPA - Car Entity Not being Worked On

So the second attempt might be to use an Intermediate Attribute. Given that the Car can have 0 or 1 mechanic (or be unknown), we could use the InstanceCount function to count the number of Mechanics working on a given Car.

OPA - Car Entity Worked On Part 2

So in the above, the Car’s workforce, a number Attribute, is used to find out the number of Mechanics working on a given Car. The other Conclusion leverages this. The result looks promising, in that the lack of a specified Mechanic gives us a “False” value.

OPA - Car Entity Not Being Worked On Debugger 2

But in the case where a Relationship is known, but there are no Mechanics assigned, such as the example below, which is obviously quite possible in a Workshop:

OPA - Car Entity Relationship Known but no Mechanic

Running our rule gives the following in the Debugger:

OPA - Car Entity Workload False Result

Clearly this is, for this contrived example, not the hoped-for behavior. After all, there is nobody working on the Car instance in this case. So our final approach might be the following:

OPA - Car Entity Relationship Final VersionWhich behaves as we would hope in the Debugger.

OPA - Car Entiity Final Result Relationship

The examples above are designed not to explain how to run a Workshop or repair your Car, rather to make you think about these useful Entity Functions. Let’s move on to another example.

We need to calculate which cars need parts to be ordered. We will base ourselves on the simple idea that cars that are older than 10 years of age, and that have nobody working on them, and that have a repair cost that does not exceed the value of the Car, will need to have parts ordered since they are not kept in the Workshop. Again, this is a spurious example for the sake of this post.

Firstly, let’s add two new Attributes to the Car Entity – the car’s residual value, and the car’s estimated repair cost:

OPA - Car Entity New Attributes

Then we can leverage the all keyword to create the following rule, with InstanceCountIf to count the number of Car instances that meet the condition.

OPA - Car Needs Parts

Finally we will highlight a further interesting example. Having calculated  the total number of cars requiring parts, let us calculate the total number of cars worth repairing per mechanic. InstanceCountIf is used in the training course ,for the purposes of demonstration, with Containment Relationships, but it is usable with a Reference Relationship as well,

OPA - Cars Worth Repairing


In our next chapter we will investigate reasoning across entities and the various functions that you can use, plus we will take a look at the French version which we didn’t have time for in this post.

Richard Napier

Author: Richard Napier

After 8 years in case management and ERP software roles, Richard Napier joined Siebel Systems in 1999 and took up the role of managing the nascent Siebel University in Southern Europe. He subsequently was Director of Business Development and Education for InFact Group (now part of Business & Decisions) for 8 years. He now runs Intelligent Advisor IT Consulting OÜ. Owner of intelligent-advisor.com, he also is Co-Founder of the Siebel Hub.

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Serving Customers Worldwide
Hide picture