Welcome to the OPA Hub!

Category Archives: Attributes

What is Happening Here – Date Function with Wrong Date

What is Happening Here – Date Function with Wrong Date

See if you can guess : What is Happening Here?

Below is a project written in Oracle Policy Automation 12 (this was actually in 12.18B but it has no bearing on the example). It has only one attribute : the date of the next visit. This is written as follows:

The date of the next visit= YearEnd (AddYears(the current date;1))

The date you are running the Debugger, the current date is November 19, 2018. The rule should perform a simple assignment, taking the current date, adding a year and then using that as the input for the YearEnd function. So :

YearEnd(November 19, 2019)

This should give the value of December 31 2019. Also, there are no other attributes in this project. There are no JavaScript extensions, no custom controls, no CSS or other additions. The project is being built using English language. The project does not have any translations, forms, or anything else inside it. But the Debugger  session of the Oracle Policy Automation Interview displays the following:

OPA 12 - What is Happening Here

The date is incorrectly showing 12/31/20. So what is happening here? Even more fun, the Data tab of the Debugger shows the following:

OPA 12 - What is Happening Here

The value is correct on the right, wrong on the left. So what has happened to the Oracle Policy Automation project in this example?

You are free to give the answer, if you know it, in the comments. I will come back in a couple of days and explain. And before you ask, yes, I can across this in the real world yesterday and it is not a bug, it did not require a Service Request, and somebody had done something. The behavior is entirely reproducible I would imagine in any language.

Sometimes you want to write about something (in my case, I wanted to look at Silent and Hidden settings) but life gets in the way. This was such an amusing thing (with hindsight) that I decided to write about it instead.

Enjoy this and hopefully you will immediately have spotted the possible culprit. You can peruse the documentation online here.

OPA – Dynamic Visibility

Dynamic Visibility

In certain situations, it is necessary to display or hide elements of the Policy Automation Interview. The easiest way to obtain this OPA – dynamic visibility is to create rules, whose conclusion can act as a basis for the Visibility. For example, if the color is red, then show the size question. And inversely – If the color is not red, then do not show the size question.

Such a method is simple and the result is attractive to the End User. It can be implemented with the Question displayed during the Interview, referencing the rule you have created. In the following screenshot you can see an example with the relevant Boolean Attribute referenced in the Attribute Input Control properties.


Mandatory and Read-Only

A similar approach can be taken to render a Question mandatory, or when a Question should have it’s Value displayed as read-only. The existence of a Boolean Attribute to reflect your business logic is once again a pre-requisite, but the process of aligning it with an Input Control is the same.



List of Values – Dynamic Values

A further area where such dynamic visibility can be useful to make the end user experience more enjoyable, is in the area of Lists of Values. If a Attribute has a List of values, some Values may need to be hidden in certain circumstances. The same dynamic effect can be achieved by associating each Value with a Boolean Attribute in much the same way as the previous examples.



Better for the End User

Simple logic such as this can increase the engagement of an End User – after all, the easier it is to complete something with the minimum of irrelevant questions or data the more likely you are to see happy End Users. Until next time, see you soon.



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.

Policy Automation – Unknown

One of the areas where students struggle at first with Policy Automation is the concept of the unknown. We’re not talking about the unknown unknown, just the known unknowns of course. Many times in the first few days of training, students see “the price in dollars is unknown” or whatever they are seeking to determine. And they are a little destabilized.

After a short while this usually goes away, but there are plenty of places where Policy Automation still surprises them and it can take a while to relate to them. Take for example the following scenario in Excel and Policy Automation:

Policy Automation - Excel Autosum Example

The picture above shows the ever-popular Excel function called Sum in action. As you will note the value for the third letter instance is null. There is no value in there. Consider it as a case where the question has not been asked yet. The Sum function sums the remaining data and proposes 22. This is expected behaviour in Excel and students can relate to it.

Now consider the following data in the Policy Automation debugger. Assume that the other two letters have identical values to the previous screenshot. This letter however has the unknown value.

Policy Automation - Unknown Attribute valueIn our Rule document in Microsoft Word we place the following standard Policy Automation function: –

Policy Automation - InstanceSum

We want to calculate the sum of the weights of all the letters. We are using “all the letters” since this is the text we have entered to describe the Collection of letters (known as a Containment Relationship in Policy Automation):

Policy Automation - Containment Relationship Text

And so we go, expectantly, to the Policy Automation debugger and review the value of “the total weight of the letters”. And Policy Automation replies with the information that the value is unknown. In Policy Automation, since the letter 3 weight is unknown, thence the total weight is unknown as well.

Policy Automation - The total weight is unknown

The above screenshot comes from the “Decision” tab of the Debugger, accessed usually by right-clicking an Attribute and choosing “View Decision”. The Sum is not known since one of the instances of the letter has an unknown value for the weight attribute. And so students are confronted with the “it’s not Excel” moment.

Equally important is the understanding that this can be detected in Policy Automation as well, with a few lines of rule.

Policy Automation - Checking for Unknown

The rule text helps us detect if the values of “the horse’s age” are all known and can proceed accordingly.

Returned values can also play a part in the management of performance in the case where Siebel is integrating with Policy Automation. If data is being exchanged with Siebel, there is a risk that large amounts of mapped data be sent to Policy Automation, especially when the Rulebase has a large number of goals to determine.

To reduce the amount of data there are a couple of options. You can add a Search Specification to the mapping in Siebel, as one solution to filter records being sent (for example Order Status = “Open”) .

In certain circumstances it may make sense instead to create two mappings. The first is used in all cases, and will provide a conclusion  in say 90 out 100 cases, but has a reduced set of Business Component mappings with Policy Automation entities.

But the presence of an unknown as a conclusion could be the trigger for a second call to Policy Automation with a different, more complete mapping, to return the second conclusion to Siebel. This second, more complete mapping would only be called one time in every ten cases for example.

Until next time.


Policy Automation – Required *

In Policy Automation, just like our old friend Siebel Enterprise, required base Attributes are highlighted to the user in the form of an asterisk, thus:-

Policy Automation - OPA Required Attribute Asterisk

You will notice that the Policy Automation asterisk is rather small. In fact, it is easy enough to not see it at all. So the question often comes up, how can we rectify this. There are three ways to approach this problem. All will require modification of files used in the Release folder of the Policy Automation Rulebase.

Option One – change the text used for all controls in all situations. Edit the messages.XX.properties files (where XX is the locale you are concerned with in your situation).

Policy Automation - OPA Release Folder Messages File Location

There is a reference in this file as follows, concerning the display of the asterisk. Mandatory text is defined as per the last entry in the section shown below.

Policy Automation - OPA Messages File Mandatory Text Example

So the text can be changed in this file. Upon running the interview again, we can obtain an improved version in this way.

Policy Automation - OPA Required Attribute Improved Version A

The text can include any of the defined authorized HTML tags such as B, I and so on for added formatting. The color of the text is defined in the appearances.properties file, under the heading mandatory-marker-text-color.

However, this solution changes the text for all controls. Suppose you wished to only change it for text controls, or boolean controls and so on?

Option Two therefore is to edit the corresponding VM file from the WEB-INF/classes/templates/controls folder. For example in the following image, the relevant code is highlighted before modification.

Policy Automation - OPA Editing Control VM file for Mandatory Text

Editing the text in the SPAN class=mandatory allows us to change the effect, in this case for a Text Input Control. A demonstration of the effect is below. In the screenshot below, the Boolean Input Control VM file has been modified. The Text Input Control VM file has been left unchanged.

Policy Automation - OPA Required Attribute Changed for Boolean Control

Finally, what if the custom effect is only to be used in certain circumstances? For example, enable the rule designer to optionally use this on certain boolean attributes but not others, in which case the normal asterisk should be shown.

Option Three – To create such an effect (and indeed, a similar technique can be used for many different reasons) requires two steps.  Firstly create a Custom Property within the Rulebase Project for the relevant Object type, in this case Control:

Policy Automation - OPA Create Custom Control Property

Secondly, within the VM template file of the relevant Control, edit in a similar way to the following. In the first part of the file, include a statement such as the example below, in order to get the value of the Custom Property and store it in a variable.

Policy Automation - OPA Boolean Control VM with added Property GetIn the same file, add conditional logic to use the desired text effect when the variable is True or False. The code below is for educational purposes only.

Policy Automation - OPA Custom Boolean Entry VM with Conditional DisplayIn this final case, the developer of the Rulebase can select to use the custom effect just by editing the Custom Property value for the desired control in the relevant Screen, as in the example shown here.

Policy Automation - OPA Custom Property in Screen Editor

So the resulting output looks like this, for False and True values respectively for the Custom Property – which can be managed, moving forward, by the Rulebase designer as needed. No further file modifications are needed to handle the conditional application of our effect.

Policy Automation - OPA Custom Property set to False for Control in Screen Policy Automation - OPA Custom Property set to True for Control in ScreenUntil next time.





Policy Automation – Folders in Oracle Policy Modeller

Readers of this blog will know that we at ODE are very keen OPA users and we love to deliver the Oracle Policy Automation training courses. These courses are generally excellent, but because of time and content constraints sometimes we do not mention things that are really obvious (but not until you have needed them).

And so today we found ourselves explaining the following:-

When you create a Project, there is a default folder structure that appears in the editor:

Folder Structure OPA ExampleSometimes when you perform actions in the Policy Modeller, such as creating Help Files, these files are added into the folders in your hard disk, but that are not visible in the Modeller:

Commentary Folder in OPA

Sometimes it is useful and necessary to display these files and folders inside Policy Modeller, for a management or just organizational reason. So how to do it? Well, if you select your Project from the Tree, then right click, you will see:-

Add Existing Folder in OPAChoosing the Add Existing Folder option and select the relevant one.

Add Existing Folder Dialog

The folder is added to your Project Tree. And of course you can use the “Add Existing File” option to display any kind of file (tip – choose “All Files”) that may be present in the folder or sub-folder.

Add Folder Results with added FilesOne obvious advantage of this is that now the Modeller can propose the options in the context menu, allowing you some control over the files without having to dip into Windows Explorer.

File Management in OPA

Simple but useful.