Tag: Inference

Back to Basics Fun with Relationships

Back to Basics Fun with Relationships

The other day I had cause to discuss Relationships with an Oracle Policy Automation developer, and as a result of the discussions and the level of interest expressed in the learning curve, I thought I would share here the project that I used to illustrate some of the main concepts used when working with them in an Interview. Firstly, to put Back to Basics Fun with Relationships in context, here are the entities we will discuss :

  • Global (of course)
  • the car
  • the passenger

The entities are in part received from another system, and look like this:

To simulate the external system in this demonstration, the data for the cars is coming from a Microsoft Excel spreadsheet which infers various vehicles. The passengers are manually entered in the Interview and then different relationships are using to construct the connections between the cars and the passengers. In this case, we need to identify the passengers in each car (which has been called the car’s passengers here), and then to specify which passenger is sitting in the front seat (which has been called the copilot here). So the car entity has the following reference relationships, both of them with the passenger but of different cardinality.

Back to Basics Fun with Relationships 3

When we look at the first two Screens there is not much to report. The first displays the cars and the second gets the passengers.

Back to Basics Fun with Relationships Cars Back to Basics Fun with Relationships Passengers

The third Screen is where some students can go wrong. The key is to display the relationship (the car’s passengers) . In the case shown, a label has been added to display the car name. Notice how the choice of display is limited to Checkbox because of the cardinality of the relationship. This makes for a situation where the user can choose the passengers and of course a passenger can only be in one car. Selecting the same passenger for two cars produces an error (as it should, even if the error message is generic).

Back to Basics Fun with Relationships Choose Passengers

  1. The relationship is added to the Screen
  2. The selection control is displayed
  3. Only Checkbox is available

The Screen looks like this in the Debugger:

Back to Basics Fun with Relationships Selecting Passengers for Cars

Finally, the fourth Screen will allow the selection of one of the passengers to be assigned as the front seat passenger (a.k.a the copilot). The Screen is displayed below and the key areas highlighted:

  1. Again we add the relationship to the Screen
  2. The cardinality means the default display option is a Drop-down, although others are available in the Toolbar this time (fixed list or radio buttons). I wish these were customizable using Control Extensions but they are not…as of 18A.
  3. The display will allow you to select a copilot, and filtering the data ensures that only passengers of the correct car are available. In this way, the first relationship (the car’s passengers) drives the second (the copilot).

The Screen looks like this in the Debugger:

Back to Basics Fun with Relationships Copilot

Finally there was a requirement to associate the copilot with the car in a more direct fashion. Specifically, the car entity had attributes to contain the name of the copilot. The basics (not complete) of this are shown below:

Back to Basics Fun with Relationships Mapping

So the car has a front seat occupant boolean attribute and the value is retrieved from the passenger entity and the copilot relationship and copied into the car attribute. The relationships and the entities allow us to retrieve data in the structure and place it in the car.

Back to Basics Fun with Relationships Data Tab

Hopefully this example will let you imagine how relationships can be used to enhance your Oracle Policy Modelling. I hope you enjoyed this Back to Basics Fun with Relationships post. As always the official Oracle Policy Automation documentation can be found here.

OPA – The Influence of inference

Policy Automation – The Influence of inference

The Oracle Policy Automation training spends little time discussing the Inference Engine. This is entirely normal since we have a very tight schedule to keep. But the Certification Examination to achieve the Certified Specialist logo has some nasty twists and turns in the question bank – they love to give our brains a workout. Of course I am not going to give you any actual questions from the Examination, but I am going to get you in the mood. Over the next few posts as you probably have already noticed we are going to be focussing on areas that might trip you up.

Perhaps the most important thing to remember is that the Examination is not all about the product (although of course there are lots of questions about functionality and tools). Some of the questions need you to think like a rule writer, not like an OPA Operator (I’m quite proud of that phrase!). So without further talking, here is the third in our series of Quiz Questions. This one broadens our fireside chat into a discussion of Inference in Interviews.

The underlying subject of the Quiz Question, and indeed of the video as a whole, is the Screen Order concept.

OPA - Screen Order

I would wager that there are a few people who have never really paid much attention to the Data Review Screen in the section referring to Screen Order. Unless otherwise specified the order of the Question Screens will be that specified in the…Question Screens folder. That phrase was slightly counter-intuitive but think of it like this:

OPA - Screens File

When you look at a Screens File, you will see a Folder called Question Screens. This is where you can create folders and order your Question Screens. And that same folder is referenced by the Data Review Screen. But it doesn’t have to be. If you have a complex set of Question Screens you can adjust the order in the Data Review Screen by dragging and dropping from the Oracle Policy Modelling Window (which itself is a pretty unintuitive action!).


OPA - Drag Drop Order Screens

Notice how you (or OPM) can exclude Folders and Screens in the lower part of the Data Review window.  So, all fine and dandy. We can create our custom Screen Order, and our new order will be respected. Except, as we show in the video, it will not be. Probably. Perhaps. It depends entirely on the Inference Engine. If a Question Screen does not have a Question on it that needs to be asked. then it will be skipped entirely. Inference means skipping questions that are not needed, if the answer to the goal question can be inferred another more efficient way. Watch the video to get a nice example.

Until next time

OPA – Jargon Buster – Determinations 2

OPA – Jargon Buster – Determinations 2

More about Determinations

As we saw in the previous post, Determination is the name and the science behind the deduction of a response to our Rulebase in Policy Automation. But it is easy to forget there are many different ways to undertake a determination.

In this final module we will look at the other ways (since we covered Web Determinations in the previous chapter) to use the engine.

Determinations Service

If you are involved in Siebel CRM projects integrating with Policy Automation you will surely come across this one. The basic concept is that the Determinations engine will be exposed via a Web Service. This Web Service is generic enough that it can be used to call any Rulebase with any number of input arguments (to populate various attributes, for example using data from Siebel). The basic outline looks a little like this:-

Consider the following Rulebase with standard boolean attributes created.

Good Dog

Now suppose we run our determination  but this this time we will use the “other” option :-

Determination Server Box

When we execute, the web browser looks like this (focussing on the parts specific to the Rulebase we just want to run :-

Generic Service List

The first five all include the word “Generic” in the service reference. We will choose the first version. The other four are for backwards compatibility, and the rest we will speak about in a moment. Click the first service reference in the list.

Web Service Structure

Nowhere in the Service will you find any reference to the dog. Because this is a completely generic Web Service, several things are now (hopefully) clear.

  • The Service contains generic components for retrieving Goals in a Rulebase
  • To pass attributes will require using a generic Attribute structure
  • To ask for a determination will require an AssessRequest to be called

This explains, in part, why integrations with Siebel require some eScripting to be done – there is a degree of standardization which will require some extra work to be done.


The final Web Services in the list previously mentioned are “interview” Web Services. It is also possible to call this Web Service and query for

  • Goals
  • Screens
  • Flows

This could be used in an “alternative User Interface” scenario where for example a Silverlight application wishes to show the correct order, structure and content of a Web Determination, but replaces the standard HTML with a new user interface.


Policy Automation – Jargon Busting – Inference

Policy Automation – Jargon Busting – Inference

Our journey through the jargon and concepts of Policy Automation begins here. The word inference (as in “inference engine” and “natural language inference”) crops up rather a lot in the introduction and description of Policy Automation.

Note : Several of these posts use sample files, which you can find here.

So what does it actually mean, and what impact does it have for us as designers or consultants? Well, let us consider a simple example. Open up your Policy Modelling application, create a new Project called “ODE – Inference”. Set the language to “English American” and the locale to “United States – English”.

Right-click the “Design” folder (inside the Documents folder) and select “Add New Word Document”. Name the Word document “Inference.doc”.

OPA -Inference Project Structure Lesson 1

Enter the text shown below in your Word document (double-click to open it). Format the text exactly as you see it here, using the following keyboard shortcuts

  • First line (Conclusion) = Alt + C
  • Both following lines = Alt + F1
  • Click the “Compile” button and OK.

Observe how the Parse window opens, confirming how the parser has interpreted your text. Importantly note that clicking the Edit button shows a total of four versions of your text :

  1. Positive the consultant is suitable
  2. Negative the consultant is not suitable
  3. Interrogative Is the consultant suitable?
  4. Uncertain The consultant might be suitable

Consultant Parsing

Let us take a moment to review what we have just entered, in order to consider the “inference” concept. We can deduce, conclude or infer, that a consultant having attended training or having followed elearning, is suitable. That part is probably clear to us. We use formatting in Policy Modelling to indicate the conclusion and the attached conditions.

OPA - Inference Lesson One Rule in Word

The basic information is the source for the inferred conclusion. But what you also need to be aware of is the reverse is also inferrable. The consultant who has neither attended training nor followed elearning is not suitable. There is no need to write this in our model, it is also inferred if the consultant has not taken either of the training options. The interrogative text will be used to present the end user with the question, and the uncertain text will be used when the data provided is not enough to provide an answer about the suitability.

In summary, with Policy Modelling, you write rules that allow the engine to reach a conclusion by reasoning and evidence. This process is called inference. And it does not really matter from a conceptual point of view how you write the rules:

OPA - Inference Lesson One Negative Conclusion

Consider the second example. Close the Word document once you have edited the text and clicked the Compile button. From inside Oracle Policy Modelling, click the “Build” menu, “Build and Run” and accept the default (first) radio button. A browser window will appear. Notice the text is shown thus :-

OPA - Inference Lesson One Interview

Although it is generally accepted practice to write  in the positive, the result is the same.

Now try entering different values. Notice how if you answer “true” to the first condition, the second one is not presented – the engine has already inferred that the outcome is the consultant is suitable. If you enter “false” for the first one, the second condition is displayed – the inference engine has detected that further information is needed to arrive at an outcome. Finally, notice what happens if you select “uncertain” for the first and “false” for the second – the inference engine can no longer provide a definitive answer in the current situation, so :

Consultant Inference

To conclude here is a little reminder of the way things “work”.

[KGVID width=”640″ height=”360″]http://www.theopahub.com/mainvideos/OPA2/Inference.mp4[/KGVID]

Jargon Busting

Jargon Busting

The world we work in loves jargon. Let’s face it, many of the terms we work with (CRM, SRF, SEM) are impenetrable to the outside world in the wide sense. Worse still, the terms we love mean various things to different people. Some Siebel-related or Oracle Policy Automation-related terminology surprises:

  • Crew Resource Management (CRM) in aviation
  • Solid Recovered Fuels (SRF)  in waste and energy management
  • Standard Error of the Mean (SEM) in statistics
  • OPA – Offre Public d’achat – public share offering
  • Oracle Policy Modelling (OPM) – Office of personnel management

Any time new students and new vocabulary meet, there is bound to be an interesting jargon busting challenge in the training room. Policy Automation is a great example. Inference, Forward and Backward Chaining, Determination, Constrained Natural Language (ha!), they all get us in a bit of a spin.

So we decided to begin a “jargon buster” micro-lecture series for Policy Automation. Read them on this blog and hopefully it will accelerate your learning as you delve into Oracle Policy Automation.

Logo by Southpaw Projects LLC