Welcome to the OPA Hub!


Category Archives: Jargon

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 #9 Testing using What If

What If?

Back in the Workshop now with all our different chapters, things are getting more and more complex. But one feature of the Policy Modelling user interface that we do not cover in the standard training course can come to our rescue. I’m talking about the What If Analysis feature. This is based on Microsoft Excel and reasonably easy to explain to a non-technical user, so it can be leverage to prove that a use case has been understood, or as a tool for working with the business to understand each other.

The use of this functionality starts with a new file in your Project:

OPA - What If Initial View

As you will have seen, the first time you open it can be quite a disappointment. What you need to do is proceed first to an initial setup, then to some data entry. Begin by clicking the Add Worksheet button on the top left, and adding Worksheets for any Entities that you intend to work with. It will end up looking like something like this, using our Workshop as the example:-

OPA - What if Added Entities

Now we proceed to each of the Worksheets and click the Add Column button. We add any attribute we intend to enter data for, as well as any inferred attributes we want to see the results for after our analysis. Notice the color coding for the columns to make it easy to see which are conditions and which are conclusions.

OPA - What If Added Columns

As in the example above, the colors indicate:

  1. Black is an identifier for the Entity on this tab. In our case here, the customer.
  2. Blur is an identifier for another Entity in the Rulebase. In this case, the Global Entity as well as the customer’s car.
  3. Green is a base attribute
  4. Brown is an inferred attribute

Entering the correct data can be a little daunting, since in many cases you will need to remember for example that car #1 is the Fiat, and mechanic #1 is Bob and so on. But you quickly get the hang of it. Common traps include

  • failing to compile your documents before clicking the Analyze button
  • failing to add information to the Global tab.

Remember that all your Entities will fold up into the parent Global, so there will need to a record on the Global tab. Go ahead and click the Analyze button and see what happens. For the purposes of demonstration, enter one car, one mechanic, one customer and one set of wheel-covers. For inspiration here is a carousel of What If Analysis Worksheets with some example data, and the results (ie, these screenshots were taken after clicking the Analyze button.

Hopefully you will see from the carousel that the inferred attributes have been updated following the Analyze button being clicked. Of course why stop there with only one car and one customer. Not only can we enter many of them for our Global Case #1, we can create many Global Cases, and associate our Entity Instances with a different Global Case.

Furthermore once you have built your complex What If scenario, you can export it to a Policy Modelling Test Case file for further testing.

Have fun, until next time

Rich@rd

OPA – Quiz Question #1 OR

A Quiz Question for you

Stepping away from our series on Entities this week, I am sharing with you all a 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.

Of course this is an easy one – it is meant to be – but it certainly helps get students thinking about how to optimize the Web Determination experience and how to structure their work. I am also a great believer in the need to include this sort of thing in training sessions. Too often nowadays it has become a “knowledge transfer” with someone reading out loud a script and a bunch of slides. I find it hard to believe that the new “virtual learning” revolution has come down to that.

Anyway enjoy and we will be back in the Workshop for more Entities Adventures very soon.

OPA Quiz Question 1 - Web Determinations

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.

OPA – Jargon Buster – Modules

Modules in Policy Automation

Considering that most projects involve teams of people, it is not surprising that Policy Automation has a team-related feature called Modules. More specifically it has a feature called Module Building and another called Module Linking. Both together provide a simple to use mechanism for working together without duplication.

The principle is very simple. Let us imagine two different people working together. The first one is responsible for creating a Common Model, and the second is going to use the Common Model in their project. But only the first will be able to update the Common Model. There are many situations that need this approach – workers deriving a new set of rules based on a common Entity model, for example. Let us work through a simulation.

In a new Policy Automation Project, create an Entity and a basic rule. To save time, you can Add Existing File from the context menu and add the Word Document and Properties File provided here.

Observe the Entity Model and Rules. It concerns horses. The Entity looks like this :-

Module Example Source

There are only a few lines in the Word document, concerning the horse and it’s weight and cost. To make this “Module” available to the other user, use the “Build” option to create the Module file. There are several sub-steps. The first is to ensure that all of the base attributes and entity elements have Public Names. This is because the Module functionality uses XML, and just like integrations, the Module needs to leverage the Public Names to create the Module File.

Build Module Menu Item

If you look at the Output Window you will see in this case the Module has been built successfully. If you see error messages regarding missing Public Names, you can correct them now.

The second surprise is that the Module does not display in your Project Explorer. This is because the file that has been generated is primarily to be used by the “other person”. Your project remains intact.

The file will be found by default in the “output” folder in your physical hard drive folder used by your Project (Project>Development>Output). The file is now ready to be used by the “other person”. Close this project and create another new Project. Add the Module File you just created by selecting “Add Module Link” from the Context menu. Go and select the Module File you created as the “other person”.  The Module Link icon will now display in your Project:-

Module Link Example

The Module gives your Project access to the Entities, Rules and translations of the source Project but in Read Only or limited visibility. For example, Build and Debug without Screens. Even though the “other person” has not actually done anything in the Project, you should be able to use the Debugger to create an instance of the horse and populate the attributes:-

Module Result Example

In addition, if you close the Debugger and view the project Build Model or click on the attributes you will see that you are in read-only and have limited visibility:-

Module View Example 2Module Viewing Example

Compare this with the view you have if you open the Source Project:-

Module Source View Example

Although this mechanism can deliver powerful features during the creation of rulebases, it can also be very important in the runtime environment when customers are accessing your Web Determination for example. Provided certain steps are respected, it is possible to “hot swap” versions of a Module file at runtime. As a simple example, the “module interface” with the outside world must be respected for this to work (attribute Ids, entity text, relationship details must not be changed). There are more details you should be aware of.

Conclusion

Modules are important as they allow sharing, linking and commonality to be implemented in a team project. Until next time!

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.

Interview

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.

 

OPA – Jargon Buster – Determinations

Determinations

Why do we need a Jargon Buster for OPA – Determination you may ask? Surely this is just “what Policy Automation does?”. The goal of this jargon-buster is to clarify just what you can do with Policy Automation, and the different kinds of ways to use it.

Firstly, determination defined – Policy Automation allows us to determine, report or calculate a conclusion for a rule or rule set. An important principle is that the data needed to determine any conclusion must come from a human being, or be transferred to Policy Automation  by another system. In short, Policy Automation does not manage or store any data for your rules outside of a session. There is no internal database in the architecture diagram.

 Web Determination

To enable a human to provide data to reach a conclusion, Web Determination is the easiest option. It uses the build in engine to create dynamic screens for data entry. But even that can cause novice users some surprises – like automatically optimized User Interfaces that don’t display all our logic. Watch this video to learn more.

Web Determination

The Web Determination has been optimized thanks to forward chaining. This automatically reduced user interface can confuse people, especially those used to building Siebel Applets that show every field under the sun! The standard, automatic Web Determination screens will only show the absolute minimum of questions to determine the conclusion of your rule or rulebase. This optimization illustrates the linear inference engine at the heart of the product. Screens and Screen Files can be used to render the Web Determination using a specific set of questions in a specific order, if required by flexible circumstances.

In the next section we will look at Determinations Server and the two ways of operating we have.

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 – Jargon Busting – Natural Language

A serious problem in the design of business rules of any kind, or the interpretation of existing legislation or jurisdiction is that most computer programs do not allow us to construct rules in a natural way.

Siebel Tools, for example, lets us use syntax like [Field Name] + [&Property Name] as well as a library of functions. This is hard to “sell” to business users when you want to give them confidence in the translation of the “paper” rules into the “system” rules.

Policy Automation increases our ability to respond to these situations by using “natural language”. This does not mean necessarily that you can copy out existing text word for word, but it does get us a lot closer. Let us see a couple of examples that will introduce key elements of the tools and the practical aspects of rule creation.

Open up your Policy Modelling application, create a new Project called “ODE – Natural”. Set the language to “English American” and the locale to “United States – English”.

Examine the text in the below”Source” document. Notice how the document is broken down into sections. This is a common feature in legal documents. Notice how the document speaks about guests, members and so on.

OPA - Natural Language Members and Guests

Using the “Design” files provided (see the previous post) let us compare. Please note, these files are just for comparison purposes and are not optimized in any way. Right-click the “Design” folder (inside the Documents folder) and select “Add Existing File”. Add both the Excel file and the Word file.

OPA Natural Language Members and Guests Rules

Some features that are important to highlight.

  • The “1” and “2” and (a)…(c)  used to mirror the structure of the source
  • The color-coded structure using strict Formatting
  • The large, clear descriptive headings in the document
  • The full text variable names at the top of the document
  • The need to still use functions (ExtractTimeOfDay for example)

Using the Build menu, select “Build and Run” and the default “Run with Web Determinations” option.

OPA - Natural Language Initial Screen

Observe that when you click on the “Why?” you are told that Section 2 has been satisfied. When correctly formatted using numbers like the example, rules will automatically generate this kind of summary. This is great for reassuring and familiarizing business people with the rules that map to their source documents.

Proceed to the session, answering that you are 18 years old, that you have spent 14 dollars and that you belong to the Paris club, and that your guest has completed the questionnaire. You should see that you are able to invite guests into the club. Click the “Why” link again.

OPA Natural Language Why

Again, the formatting has reproduced the structure of the source. Now replace the existing Word file (Right Click, “Remove File from Project”) with another version “Design2”. Observe how the structure of the Word document is slightly different (but the content is the same). In Policy Modelling, the format of the text is all important, since it tells the engine several things

  • What the conclusions and main goal are
  • What the structure of the logic is (Level 1, Level 2 formatting)
  • How to parse the content of your Word file (where the “questions” are)
  • What text to ignore (Heading, Comments, Blank Lines)

The formatting is achieved by use of the Policy Modelling toolbar. Rerun your “Build and Run” with the same data as before, notice the “Why?” this time matches the original text, because of the changed structure of the file. (Note in the example below, we set the “closing time” of the club to 6pm…)

OPA Natural Language Guest Accepted

In Policy Modelling, there are often multiple ways to write something, but we must balance writing fast (less understandable) and writing well (helping the business understand the correlation with the source text), all the time writing “understandable” sentences for Policy Automation using the correct formatting. We can come close to natural language, far closer than ever before.

Finally, change the computer clock to a “closed” time, or carefully edit the Word document to be “closed”. Rerun and observe you are not even able to begin the question and answers, because :

OPA Natural Language The Club is Closed

This is because of another jargon item, which we will discuss in the next post.

PS – the “club rules” used were inspired by documents like this one.

PPS [Note : Orginal Attached Files that belonged with this post have been removed. If you want them please contact the author]

Policy Automation – Jargon Busting – Forward and Backward Chaining

Forward and Backward Chaining are important concepts to help understand the reality behind the Policy Automation engine. Forward chaining is known as data driven inferencing, since we begin with the data we have and attempt to reason our way to the answer. Computer systems can use this to iterate through a process until the conclusion is found.

For example :

Create a New Policy Automation Project and add a single Word Document called “Chaining”. Open the Word document and enter the following rules.

OPA - Forward Chaining The Candidate

 Forward Chaining

“If” you have given a good interview “then” you are an acceptable candidate. If you are an acceptable candidate, you will be offered a job, if you are offered a job, you will be given a salary and so on. The engine is good at responding to new data – it immediately triggers new inferences. The data received determines which rules will be selected and used.

Forward chaining is common in programs where there is a degree of user input.

OPA - Forward Chaining

Backward Chaining

Backward chaining might sound a bit, well, backward. It starts from the conclusion and then works backwards to see if there is data to support the conclusion.  If we consider “the candidate can have a salary” as the conclusion, the system will look at “the candidate gets a job offer”, then look to see if it has any data to support this, and so on backwards.

A good example of backward chaining in computer games is the chess model. In chess, there are finite numbers of moves to reach a “winning position”. To calculate all the possible ways to reach a given “winning position” it can chain backwards and build a table of possible “ways to get to the winning position”.

OPA Backward Chaining

It’s everywhere!

Reasoning, inference, artificial intelligence and other engines (think of chess computer games – they include backward reasoning to compute the different ways to get a “checkmate” conclusion) use these different methods. There are lots of details and references on the net.

Semantic Web

 

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]