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
- 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.
]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.
[vc_single_image image=”” img_size=”full” alignment=”center”]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.
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.
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.