Welcome to the OPA Hub!


Tag Archives: Functions

Temporal Reasoning in Oracle Policy Automation #2 : Time Travel

Temporal Reasoning in Oracle Policy Automation #2 : Time Travel

Following on from the previous post, this short series is looking at temporal reasoning. In the initial post we investigated the basic principle of entering temporal data in the debugger and using a function such as ValueAt() to get the value of a temporal attribute on a given date.

Now that we have laid the groundwork, we can extend our range a little. The first scenario to discover requires us to have the data in the debugger just like last time, with data for the first few days in July. If you are not sure of the scenario then jump right back to chapter one.

When did you last have lots of money in your account?

I’m sure I’m not the only one who sometimes looks at my bank account and feels a little depressed! The bank balance seems to go down and down, then spikes up on pay day and down and down again. I often ask myself, when looking at something nice in a shop or showroom  – a car for example – when did I last have that kind of money?

Thankfully, Oracle Policy Automation is here to help answer that question and many others in relation to temporal data. The following function will hopefully illustrate this example:

OPA 12 - Temporal Reasoning Part Two 2

You can probably guess the idea. Working backwards from the current date, when did I last have a value greater than 1500 in the temporal bank balance. Now, if you have been using the same example data as me, this function will currently return a value of uncertain. That’s because none of the data in the debugger at the moment is greater than 1500. But if you add a new Change Point to the temporal bank balance, for example :

OPA 12 - Temporal Reasoning Part Two 3

Then your debugger should provide you with a more definite answer. In my case, you can see that June 14 I had a change to my bank balance and it was 1550. The next available change point is July 1, when the value was 1000. So when did I last have more than 1500 in my temporal bank account? Following the change point data, the last date I had that amount of money was June 30. You might suspect that I spent my money faster than that 🙂 but we can only work with the facts, and the change points are those facts.

It won’t come to you as a surprise that there are many functions in the Function Reference for finding out values, and one of them is described below. It belongs to a series of functions prefixed with Interval.

OPA 12 - Temporal Reasoning Part Two 4

This one, as the goal suggests, helps me find my lowest bank balance in the period between the start of the year and today, based on the information in the change points. It will obviously depend on your data, but you will probably have something like this.

OPA 12 - Temporal Reasoning Part Two 5

In the next post we will continue investigating members of this family of temporal reasoning functions.

Oracle Policy Automation Quiz Question Two – AND

Oracle Policy Automation Quiz Question Two – AND

Many of you probably saw this one coming after the first Quiz Question. Well, here it is.

I am sharing with you all another question I often ask during the Oracle Policy Automation training to my students. I ask it for three main reasons

  1. It helps to understand the Engine and the inferencing process
  2. It’s fun and a great way to challenge yourself
  3. It is good preparation for the sort of question that you might get in the Certification examination.

This is quite an easy one, and most people will get it right away

Something to think about

The Oracle Policy Automation  Certification, as it is sometimes called (incorrectly) is in fact actually called “Oracle Policy Automation 10 Rule Developer Essentials 1Z0-534” and as such is focuses for the major part on rule development. The exam study guide seems to have gone 404 on the Oracle University Website but the corresponding guide in the partner website is still useful.

Update in 2016

Of course, since this article was originally written for Version 10, things have changed – not least with the arrival of a Cloud-focused certification examination that, at time of writing in December 2016, was undergoing beta testing. Although there are currently no self-testing or exam guides yet available, I hope this is just a matter of time.

OPA – Entities Adventures #10 Temporal Reasoning

Temporal Workshop

And so we come to the tenth, and final (for the time being) post in this hopefully useful and entertaining series for learners of Oracle Policy Automation. In this episode we will discuss the concept of Temporal Reasoning and apply it to the Workshop example we have been using since the beginning of the series.

What is this temporal stuff?

To give you a simple example, our Workshop has a variety of elements to it that change over time :-

  • Cars in the Workshop
  • Mechanics
  • Car Storage Cost

And of course, these pieces of data might need to be analysed and calculated over time. This is a common thing in business of course. Generally software tries to handle this by having “data points” – snapshots of data – but usually they are not very good at handling “periods of time” – where you don’t have data for each day or other time period  but you expect to have to calculate as if you did. Say for example you have a person who receives money from the state. They receive it on a weekly basis. We need to calculate from their date of first receipt, until today. So we need to be able to “span the time period” and calculate the figures. And that is pretty cool.

How does it work in Policy Automation? – an example

In Policy Automation, we need first to understand how the data is entered. Let’s focus on the storage costs – cars that are left in the Workshop are charged at a daily rate to the customer, for storage, once they are left more than 3 days. In addition, the storage charge is a percentage of the value of the vehicle. Finally, storage of more than 10 days gets a higher rate.

So let us work up an example. Assume two cars being worked on in the Workshop. One of the them arrives in the Workshop on September 11, the other on September 1. Today is September 17. So how much storage should we charge? To make matters more realistic, we can say that the first ten days are charged at 9% of the car’s residual value, the next ten days at 11%, and beyond that a punitive 15% since the car has really been here too long.

OPA - Daily Cost of Storage Temporal Example

In the above example we introduce some new Attributes (the cost of the car’s storage and the date of the car’s arrival) respectively currency and date types, and the function TemporalBefore().

From the Function Reference we see that TemporalBefore (date) is explained thus:

Returns a Boolean attribute that varies over time and is true before a date and false on and afterwards.

So essentially our cost will be calculated using the car’s residual value * 0.09 for as long as TemporalBefore(AddDays(the date of the car’s arrival, 10)) is TRUE.

There are other versions of this function to handle things like “on or before” or similar calculations for “after” or “on or after” dates.

Visualising the data in the debugger makes it clearer how this is working. Don’t forget to right-click the cost of the car’s storage in the Debugger window and choose Show in Temporal Visualisation.

Now we can see the cost of storage incurred based on the car residual value and the arrival date of the car, according to the different values over time. But perhaps you didn’t see what you were expecting – the actual total cost as of today. So let us introduce this into the mix:-

In the following screenshot, note we have added new “total cost” and “current daily cost” Attributes.

As a demonstration we are using the ValueAt() function to get the current value charged today (according to our table of values).

We are also using the IntervalDailySum(start, end, value) to calculate the total amount payable to date.

OPA - Car Storage Cost Rates and Total Temporal Function Example

Now that we have the total cost of the storage, we can go ahead and work out if the car storage has exceeded the residual value of the car.

And so we come to the end of this 10 part series, designed to give you some more fun examples of working with Entities. For those of you who are reading this after taking the OPA Essentials Class with me, I hope you enjoyed them.

What Next?

For the next series of posts we will be looking at teasing questions that might help you prepare for the certification. After that, get ready for more function examples and fun with Oracle Policy Automation.

Rich@rd

OPA – Entities Adventures #8 IsMemberOf()

More Functions

Policy Automation has a vast array of Functions that can be called into service at one time or another. Many of them are very specific and we will try and discover a few more of them before the end of this series.

But we can take this opportunity to share with you a couple of “cheatsheets” that we give out sometimes in the Policy Automation training courses. These are PDF files with examples of lots of useful Functions from Oracle Policy Automation.

If you get Error 500 just click the Back button and try again

[stamper_download_button_for_wp_user file_url=”http://www.theopahub.com/mainfiles/OPAL/STRING/TextFunctions.pdf” button_text=”Download Text Functions Now”]

[stamper_download_button_for_wp_user file_url=”http://www.theopahub.com/mainfiles/OPAL/DATETIME/DateAndTime.pdf” button_text=”Download Date Time Functions Now”]

The Workshop

In this episode we will consider another key function

1) The IsMemberOf Function

This function can be useful in determining membership of a Reference Relationship. It is called “inferred membership”

To begin let us examine the scenario for the IsMemberOf function.

IsMemberOf

The IsMemberOf function (or “is a member of”) can be used in two different ways. Firstly as a conclusion, but also as a condition. Let us take a look at them both in a practical example.

Back at our Workshop we want to find out which cars are Italian, since they may require expert care and attention. We might be tempted to write something like this almost straight away, so simple this function sounds.

Hopefully you can see there is a problem. The New Attribute dialog box which appears when you click Compile is showing two boolean Attributes. That does not sound like what we need to make this work. In fact we need firstly to create our “Italian cars” – specifically we need a Relationship to hold the cars we are looking for.

When we compile our simple rule after this, there is a difference:-

And likewise, our Word document shows that the IsMemberOf function is now correctly included in our conclusion.

If we build and debug our rulebase, and populate the new Boolean Attribute “The car is serviced weekly” for each car in the workshop, we will be able to see the results as shown below.

Notice the yellow icon and the nature of the relationship – it is inferred and cannot be directly changed. Only by editing the Boolean Attribute can we change the members of the “Italian Cars”.

IsMemberOf as a Condition

The same function can also be used as a Condition. For example :

The syntax is straightforward as you can see.

Conclusion

The IsMemberOf function gives us flexibility to create inferred relationships.

OPA – Entities Adventures #7 Scope in OPA …

Back to the Workshop!

In this episode, we will look at the subject of cross-entity reasoning again to investigate some functions which we do not cover in the Policy Automation training. Firstly though, we need to talk about Scope.

Scope

Many users of Policy Automation will be familiar (and not in a good way) with “X is not in scope. You may need to use an alias when referring to the X”. It’s one of those errors that most people will get in the construction of rules. To make matters worse, sometimes juggling the rules and changing the order, or moving them into different files, and the error goes away. So what is going on?

Firstly, we need to understand how the Word Compiler works. For it is the Word Compiler we need to think about. The Word Compiler works from top to bottom down the page. And as it works down the page, it uses the entity instances defined in the previous line, as the scope of the current line. Let’s extend our rulebase and focus on customer satisfaction to demonstrate.

Add two new entities, the customer, and the wheelcover. Make sure the wheelcover is a child of the Car entity.

Add the relevant Reference Relationships and make sure the Relationship Text is suitably friendly

Scope in our Word Document Example

Now Consider the following piece of rule text from Microsoft Word. Notice the “cascading logic”.

In the Conclusion, we set up the initial scope as the Customer. In the first line we proceed to “narrow” the Scope to the Customer’s Car. This is acceptable as there is a Relationship defined with the Customer as the Source and the Car as the Target, and it is One to One.

In the next line, we scope down to the Car’s Wheelcovers. Again, as the Customer’s Car was in scope in the previous line, this is acceptable as the Car has a Child Entity called the Wheelcover and there is a Reference Relationship in place. Finally in the last line we have a condition that references the Wheelcover, since it is in Scope.

For completion we show both the terse and the long form. Since the Word document may continue to have further rules in it, you always need to be vigilant about setting scope clearly in each of your rules.

In addition, we need to choose the correct function depending on the nature of the Relationship. In this respect the Function Reference is useful.

In the next episode we will continue our Workshop and build out the various logic we promised a few chapters ago, as well as continuing our Function discovery.

Until next time!

OPA – Entities Adventures #6 Cross Entity Reasoning

Cross-Entity Reasoning

Once again we return to the Cars and Mechanics in the mythical Workshop. The first part of this post will review the French version of the work done in the previous episode, and then we will undertake some cross-entity reasoning using the various functions at our disposal. Catch up with the rest of the series (12345)

The French version looks like this in the Web Determination window. First off, the basic structure is exactly the same and there are no challenges to report.

OPA - French Workshop

Eagle-eyed viewers will notice there is a problem (that we raised earlier in the context of Gender but now is as good a time as any) concerning the title of the page. In fact, despite the Project being French Language and French Region, all the labels are in English (“Data Review”, “Assessment Summary” etc.). You could be forgiven for thinking these came from the “Appearances Property File” in your Release folder:

OPA - Messages FR Properties

But no. The titles that I just mentioned are generated when you add a Screens File to your Project. So even though we have a French Project with French as the Rule Language, we get English titles!

OPA - Titles in English

Common Trap Number #10 – Screen Titles in the wrong language

Irritatingly enough the way to fix this (if it can really be called fixing) is to switch the Language of Policy Modelling to French before you start, in which case when you add a Screens File you will see valid Titles:

OPA - French Screens Titles

Then you can switch the editing language back to English and at least you have the right titles in your Screens File. (Tools > Options > UI Language). I know it sounds silly but there are many occasions when you want to create a Project in another language but you don’t want Policy Modelling User Interface to be in that Language.

Switching back to the English version of our Project, we can now get into some more Functions, specifically cross-Entity functions. These functions are designed to cope with the need to cross from Car to Mechanic in a rule. For example

Consider the fact that Mechanics exist in several types – Expert, Confirmed and Novice. We want to write rules that say

The Car will be ready on time if the Car’s Mechanic is an Expert.

The Workshop is running efficiently if at least 2 cars are being repaired by Experts

The Car, the Mechanic – these are our Entities. The Workshop, our “singleton parent Entity” is the standard Global parent Entiity proviided by Policy Automation.

Let’s look at the Function Reference for the For function that will be useful in our case. We are able to reason cross-Entity, as long as the Relationship type is correct (and between Car and Mechanic it is Many-to-One), and there is only one Condition (the Mechanic is an Expert.

Assuming you take a moment to create an Attribute “The Mechanic’s level” of type Text, then you could examine the following from the Function Reference and get writing.

OPA - For Function Reference

As is often the case, there are long and short versions. There is nothing stopping you using one, or other of these versions as you prefer, interchangeably. But look closely and you will see the definition of the Function has some differences. The short or “terse” version “For (relationship, expression)” looks like this when we write it out: The following should compile.

OPA - For Terse Version

 

Common Trap #11 Assuming All Versions of Functions have the same syntax

But suppose you decided to write using the Long form, “in the case of“. The Function Reference gives a slightly different explanation for that version, if you look closely. It says “in the case of relationship, attribute”. Which is not the same thing as the previous example, And indeed, the example below does not compile.

OPA - For Long Version Error

 

The following example does however, Notice how in this example we have changed the “level” to be a Boolean attribute rather than a Text attribute. It would appear from the Function Reference that the long version is only possible with a Boolean. And that may mean you end up creating an intermediate rule like this:

OPA - For Function Intermediate RuleAnd that may be something you do not need or wish to do, so you decide to use the terse version. But before you give up on the long version, you see there is a third option in the Function Reference “<val>, in the case of <relationship>”. Interestingy, the “<val>” acronym appears only once on the entire list of Functions. And it is far from clear what it actually means. So best to avoid that.

Next time, we will continue and use some other Functions!

 

Policy Automation – Jargon Busting – Temporal Reasoning

Temporal Reasoning

Temporal Reasoning in Policy Modelling is the capacity to deal with Change Points and data that varies over time. For those of you who are familiar with the Siebel CRM, a similar concept was introduced to Siebel Public Sector 8.2 called “Effective Dating” for certain components that needed to be configured in this way (for example, the case of a person who changes their name, effective 1/1/2014). They had a name before and they had a name after. So the attribute or field name is the same, the value changes however over time.

To illustrate the point and observe the capabilities of Policy Modelling briefly, create a new Project and call it “TimeTravel”.

In the project, add a New Word Document. As is often the case in these brief examples, for the sake of speed we are skipping over items that we do not need to mention here, specifically some best practices have been sacrificed in the name of speed.

Temporal1

Type the text above and make sure you select “the cash” and click the “Add Attribute” button and create an attribute of type Currency. Do the same for the “the last good day” attribute but make sure you have created it as type Date. The Attribute Editor button will let you review your work.

AttributeEditor

Now Compile the Word Document. So far it would appear that there is nothing very special about our project, save the use of a new Function called WhenLast(date, condition). Now let us complete the exercise. In the Policy Modeller, Build and Debug (without Screens) or just press F5. The usual screen will appear. We will enter some information into the debugger. Double-click “the cash” to enter the value. And proceed in the following fashion:

Temporal2

Click the Change Points button, and proceed to enter a series of Values for different dates. Make sure one of them is over 100, and make the most recent one less than 100. You are providing the raw data that the “WhenLast()” function requires. When did you last have 100 $ (or whatever your regional currency setting is) in your bank account? The last good day is designed to be inferred from the data you are entering.

CashSetup

So in the case above, there are various dates and figures. Now we can see in the debugger :

Temporal Result 1

If we right click “the cash” we can select the “Show in Temporal Visualisation” option, and click the “Temporal Visualisation” tab in the Debugger. Notice the display, and how the initial value entered (77 in the case above) is used to seed the attribute with its initial value, and the other numbers are entered according to their change points. If you remove the 77 from “the cash” Value field, you can choose “uncertain” or “unknown” instead.

Temporal Result 2

Clearly such a simple example cannot do justice to the different Temporal Reasoning functions but where data is presented for analysis with change points, now you know to consult the Temporal Reasoning section of the documentation.

Policy Automation – Function Examples – Date Time Functions

Policy Automation – Function Examples – Date Time Functions

The Policy Modelling tools we look at in the Oracle Policy Modelling training courses are complete with a list of functions for use in building rulebases. Unfortunately there is not always an easy example to accompany the function explanations. In fact some students find them quite hard to decipher.

From time to time we aim to provide function examples for the provided Policy Automation functions. Whilst there is the documentation, and the function reference, sometimes it is just plain easier to have a set of examples in a Word Document ready to use. This week we are happy therefore to let you know that from the ODE Subscriber Bonus Page you can download five pages of Day, Week, Month, Year, Weekday and other related functions for your viewing and using pleasure.

Policy Automation - Date Time Functions

Bonus Download
Note : the attached file has been removed. If you are interested in that sort of thing, read my book, you can purchase it online or as a real “paper” book. It is available all around the world thanks to Amazon and other online retailers. I can probably find this Word document somewhere in my archives, but bear in mind it was used with Version 10 so you will need to do some work on it.
 
See you next time!
Also in this series : String Function Examples.

Policy Automation – Uncertain and Ambiguity

Since we were speaking the other day about unknown knowns and so forth, it seems appropriate to address the subject of uncertainty, at least as far as simple Policy Automation rules are concerned. Uncertainty of course has a bit more impact when you talk about other forms of automation, such as autonomous vehicles.

Anyway, on with the discussion. Consider the following simple rules:

Policy Automation - Horse AgeThe above scenario assumes the existence of an Entity called the horse, whose Containment Relationship is called all the horses, as well as various attributes which are shown below for clarity.

Policy Automation - Horse Entity and Attributes

Policy Automation - Global Attributes

When we start the Debugger and enter data, all seems perfectly fine, and we get conclusions that are logically correct and inferences that make sense.

Policy Automation - The Oldest Horse Version A

But when we change the data to propose that more than one horse has the same age, we get a surprise. The InstanceMaximum function continues to return a value, since there is still a highest value (irrespective of how many horses have the same value for their age).

Policy Automation - Uncertain Horse Name

However, the InstanceValueIf function reports that the name of the oldest horse is uncertain. That’s because InstanceValueIf returns a value if it “Obtains a value from a unique entity instance” which clearly is not possible here, and furthermore “If more than one target instance meets the condition, then Uncertain is returned.” The text in quotes is from the Function Reference which you can access from the Policy Modelling application via the Help > Function Reference option.

So we need to be prepared to manage this situation, both in a Web Interview and perhaps more so in the case of a determination via Web Service. In the case of Siebel integration for example, it may not be possible to ensure that distinct records are sent to the determinations server for processing (there are Siebel Business Component User Properties to implement Distinct as a Query criteria, but that may not be appropriate and may require duplicate Business Components and other effort that is not acceptable.)

So how can we signal that issues such as this have occurred? The approach will differ depending on the nature of the missing data. For example, if you are checking that all he instances have a certain attribute populated, then :-

Policy Automation - Missing Data

But it is better to simply leverage the uncertain value, which is designed for this very purpose:-

Policy Automation - Uncertain Horse Name 2

On the other hand, if you are checking for the existence of two horses with the same age, things become a little different in Policy Automation. We will need to use the functions designed to refer from one entity to another, and specifically to use an alias to compare instances without Policy Automation going into a tailspin.

Policy Automation - Comparing Instances without Ambiguity

In the above example, we use ExistsScope with the additional “the other horse” alias which is enough for us to be able to reference an attribute of the horse (the horse’s age) and compare it to the age of the other instances of the same entity. Policy Automation - Horse Data in Debug

Thus in Debug without Screens, upon entering 3 horses, two of which have the same age, we see the above. And when we click the “View Decision” option from the right-click menu, we can see the data is as follows:-

Policy Automation - Debug Data View

Silver and Danny Boy have identical ages.

 

 

 

Policy Automation Function Examples – String Functions

Policy Automation Function Examples – String Functions

The Policy Modelling tools we look at in the Oracle Policy Modelling training courses are complete with a list of functions for use in building rulebases. Unfortunately there is not always an example to accompany the function explanations. In fact some students find them quite hard to decipher.

So today we are going to give a few Policy Automation Function Examples and some interesting commentary. Our first function area will be the concept of string functions, and in future posts we hope to cover some other areas as well. All of the following (with one minor exception, which we have added for the purposes of using example data) are used to return, modify, convert or otherwise do something to strings (text).

In the following rulebase, we created some attributes for Policy Automation which you can see below, that are used in the function examples.:
Policy Automation - Variables for Text Functions
And here are the different String functions, each one with a short explanation above. 
Policy Automation - String FunctionsBonus Download

 Previously on this website I hosted PDF versions of the String Function on blog posts. You can now find them in my book, Getting Started with Oracle Policy Automation, or of course just download them from the ODE OPA Shop.