Category: Entity Model

OPA Entity Model Viewer 1.0

OPA Entity Model Viewer 1.0

Edit : 5/5/19 updated version available (see Shop for details)

As many readers will know, I was a fan of the Oracle Policy Automation 10 feature which allowed you to visualise the entity model of your Project:

OPA Entity Model Viewer

A while ago I wrote about an idea I had, to use the same library (Mindfusion Diagrams for Windows) to build something like it. Since the advent of version 12, the way the data model is stored as changed somewhat and for various reasons, this feature is no longer in Oracle Policy Automation 12. And I think that is a shame. So I decided to keep going with the idea, and the result is the small application which I would like people to download and tell me if it works for them.

It is a ClickOnce application, that is easy to download and install. It runs by letting the user view the contents of projectDatamodel.xml (which contains most, but not all, of the interesting bits of your data model.

It has various features. It can let you see the entire data model, including enumerations, and links:

OPA Entity Model Viewer

It also allows you to view the enumerations (value lists) associated with entity attributes:

OPA Entity Model Viewer

You can see in the above picture that it also shows public names for attributes  – great for finding those you have forgotten about. You can move the items around the page, zoom in and out, even just play with the layout until it is perfect. Some of the larger entity models might need a bit of moving around!

You can contract and expand all the entities if they are taking up too much space. You can also add the hidden upload pseudo-attributes to your diagram, if you are using the new Upload Group feature introduced recently:

OPA Entity Model Viewer

You can of course print the output – to any printer or PDF generator. And you can save it as an SVG which is good for embedding in other programs.

OPA Entity Model Viewer

There are a bunch of preferences, including the colors used for the diagram. Some of the more interesting options don’t actually do anything yet.

OPA Entity Model Viewer

So, what am I getting at? Well, I’ve tested it on a bunch of 18D and 19A projects including the sample projects and some of my own. They all seem to work reasonably well. But of course, it only will be when lots of people test it, that I’ll know of any weirdnesses. And heaven knows, there will be plenty. I’m just a recreational coder, so I’m not looking for a sellable product. But if I can get rid of most of the obvious things, then I will be happy.

If you are interested, please download the Zip from the OPA Hub Shop and install it, and let me know if anything goes strangely. Just leave a comment an help with the OPA Entity Model Viewer!


Visualize the Data Model in Oracle Policy Automation 12

Visualize the Data Model in Oracle Policy Automation 12

One of the very few areas where I feel that Oracle Policy Automation 10 is slightly better than Oracle Policy Automation 12 is in the area of visualisations. You may remember that in version 10, getting a visual representation for the data model was very easy. To visualize the Data Model in Oracle Policy Automation 12 is not so easy!

Visualize the Data Model in Oracle Policy Automation 12 - Data Model

And what was particularly useful was that it could be copied and pasted into Word or PowerPoint or any other productivity tool.

So the other day I was stuck on a plane and I began to think about this from an Oracle Policy Automation 12 perspective. The data model is stored, as you probably are aware, in the file called projectDataModel.xml which is in the Project folder. It is updated live as you add things to the data model via the Data tab of the Oracle Policy Modeller.

In this file there are, simply put, three sections. Entities and Attributes and Relationships.  There are other sections but these are not of interest today.

Visualize the Data Model in Oracle Policy Automation 12 XML

Oracle Policy Modeller 10 used a third-party component family, Mind Fusions – notably the Diagram Control (from to do a lot of the heavy graphical lifting in the old interface. That component is not, to my knowledge, used in Oracle Policy Modelling 12.

So what if we decided to use it again? The Mind Fusion controls are available as a free trial download. so I popped them into my free Visual Studio 17 and began to think about how to get this up and running. Remember, that this is not professional code because that is not what I do. It’s supposed to be interesting and valuable but you will have to do it properly yourselves.

Firstly, the XML structure is very simple indeed, so loading it into a DataGrid was a matter of a few lines of code. Create a DataSet, load the XML and display it as the data source of the DataGrid.

Private Sub btnLoad_Click(sender As Object, e As EventArgs) Handles btnLoad.Click
        Dim fileDialog As OpenFileDialog = New OpenFileDialog()

        fileDialog.Title = "Open File Dialog"
        fileDialog.InitialDirectory = "C:\Users\SADMIN\Desktop"
        fileDialog.Filter = "XML files (*.xml)|*.xml|All files (*.*)|*.*"
        fileDialog.FilterIndex = 1
        fileDialog.RestoreDirectory = True

        If fileDialog.ShowDialog() = DialogResult.OK Then

            FileNameAndPath = fileDialog.FileName

            dataGrid.DataSource = dataProject
        dataGrid.DataMember = "entity"
        dataGrid2.DataSource = dataProject
            dataGrid2.DataMember = "relationship"
        End If
    End Sub

So now we can display the data in a Grid. Boring, but useful.

OPA 12 - Data Model Visualisation Load DataGrid

The next step is to find out how to display the data in a Diagram. Since the Mind Fusion Diagram control is thoroughly modern, we need to add both a Diagram and a DiagramView to our Project. Then we can load the data into the Diagram, creating Nodes (boxes) and Links (connections) as we go.

I broke it into three steps : Global and it’s attributes, Child Entities and Attributes, and finally Relationships. All Nodes can have a tag so it is a good idea to store the unique identifier in there, which makes it easier to find the correct “source” or “target” for anything you want to do with your Nodes.

Here is a snippet from the initial build up of Child Entities:

    Private Sub CreateFirstLevelChildren(ByVal parentDiagNode As DiagramNode, ByVal parentXmlNode As XmlNode)
        ' Create a loop for all the entities in the XML
        For Each element As XmlElement In parentXmlNode.SelectNodes("entity")

            If element.GetAttribute("ref") <> "global" And element.GetAttribute("containment-parent-id") = "global" Then
                ' find all the first level children and add a new shape
                Dim node As ShapeNode = Diagram1.Factory.CreateShapeNode(nodeBounds)
                node.Brush = New MindFusion.Drawing.LinearGradientBrush(Color.Yellow, Color.BurlyWood, 20)
                node.Text = element.GetAttribute("name")
                node.Tag = element.GetAttribute("id")
                node.Shape = Shape.FromId("DividedProcess")
                'draw a line between parent and child
                Diagram1.Factory.CreateDiagramLink(parentDiagNode, node)
                'get the attributes
                CreateAttributes(node, element, element.GetAttribute("id"))
                'get the children of the child
                CreateChildren(node, element, element.GetAttribute("id"))
            End If

    End Sub

Given that the Mind Fusion Diagram supports Printing, Zooming and Saving to SVG or Visio, this means that you can be up and running in no time. I experimented with different viewers hooked in to some simple XPath-based searches of the XML file:

Standard Viewer

OPA 12 - Data Model Visualisation Load Viewer

The standard viewer let’s me move things around and generally get a good view of the data model. In addition, as I mentioned you can output to PDF, SVG or Visio. Pretty neat! I experimented with the relationships loaded on top of the data model and it can get pretty crowded, but now we can visualize the Data Model in Oracle Policy Automation 12.

OPA 12 - Data Model Visualisation Load Viewer Crowded

3D Viewer

Less flexible and probably misused in this case, the 3D Viewer looked good but didn’t really offer anything over and above the standard Viewer.

OPA 12 - Data Model Visualisation Load 3D Viewer

It just looked neat, I grant you!

Given that Office 2016 supports SVG Vector files – and for that matter PDF files – it was then a simple task to copy my data model into PowerPoint just by Saving As.

  If SaveFileDialog.ShowDialog() = DialogResult.OK Then
            Dim svgExp As MindFusion.Diagramming.Export.SvgExporter = New MindFusion.Diagramming.Export.SvgExporter()
            svgExp.ExternalImages = False
            svgExp.Export(DiagramView1.Diagram, SaveFileDialog.FileName)
        End If

See how easy it is! I really save time when creating slides and documents.

OPA 12 - Data Model Visualisation Load Viewer PPT

Visualize the Data Model in Oracle Policy Automation 12

That’s enough for now. If you are interested and want a copy of my kindergarten code just leave a comment and I will pass it on. My next job is to add a few options (Show / Hide attributes and the like, to make the content a little more customizable), and to investigate the Visual Browser concept that we had in Oracle Policy Modeller 10. That, on the other hand will be much more difficult!

OPA 12 – It’s all in the Natural Language Text

OPA 12 – It’s all in the Natural Language Text

OPA 12 – It’s all in the Natural Language Text

I suppose this article could have just as easily been about Oracle Policy Modelling 10 as well. But since I was teaching version 12 I decided to use it for the screenshots. I also was teaching a group of French students so the examples are in French and English. Ultimately the same challenges occur no matter what language you are using, provided that language uses definite articles in the same way. Natural Language is not always natural.

Consider the following :

An Entity called “the contact” or “l’interlocuteur”.

OPA 12 - Contact Entity Natural Language

As you can see, the Relationship Text has been changed to “tous les interlocuteurs” or “all the contacts” instead of the standard “all instances of the contact” or “toutes les instances de l’interlocuteur”. I see a lot of students working in this way. However there are some side effects of using this kind of wording…

Let’s imagine that every contact has a telephone number, and we want to check that the telephone number has been entered. The first part is fine, we can write the following rule to assign a Boolean value depending on whether we have a telephone number or not, and let’s build a rule that uses Entity Quantifiers to look at the different contacts.

When is Natural Language really Natural?OPA 12 - For Each of the Contacts Natural Language

In English we would have something like

OPA For Each Contact in English Natural Language

We are using the longest version of the “natural language” Function “ForAll“. And it looks a bit, well, long-winded. So we might try one of the other versions:

OPA 12 - For Each of the Contacts EN Part Two Natural Language

That’s even worse. In French too it’s almost comical …

OPA 12 - For Each of the Contacts FR Part Two Natural Language

That’s even worse. So let us try a different approach. We decide to modify the Relationship Text and remove the “all” to leave only “the contacts” or “les interlocuteurs”. So now our rules look a bit more “natural language” when we use the ForAll function in it’s long form.

OPA 12 - For Each of the Contacts EN Part Three Natural Language

OPA 12 - For Each of the Contacts FR Part Three Natural Language

Of course I can hear people saying, why don’t you just use ForAll or PourTous – that is, the terse or short version of the function? It does of course depend on your environment, but a non-technical user is going to be far more comfortable using a natural language-based solution.

Have fun improving your text, 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!


OPA – Entities Adventures #5 Entity Functions…

Entity Functions

Moving forward in our investigation of the Oracle Policy Modelling and the Entities we have created, we can now begin to leverage some of the common Entity Functions. Consider the following requirements

For each car in the garage, indicate if it is

  • Being worked on
  • Requires parts to be ordered

At the same time, indicate the profit expected from each vehicle. Based on this figure

  • Indicate cars worth repairing, for each mechanic

How can we decide if a vehicle is being worked on? In the Policy Automation class which I teach very often, we create an Attribute “the car is being worked on” (Boolean). In the example in this post, we will use another method which may or may not be appropriate for your business requirement.

First let us consider the nature of the relationship. Each car can have 0 or 1 mechanic. A mechanic can have many cars. So our first attempt might be using the Exists function, which can detect at least one of a specific Relationship, and can apply one condition.

OPA - Entity Exists

The initial result is promising since with populated data and Relationships known, the Debugger displays:

OPA - Car Entity Being Worked On

The downsides are that the Attribute value will be “Unknown” if the Relationship is unknown, which can confuse the User. Observe the Debugger showing the result below.

OPA - Car Entity Not being Worked On

So the second attempt might be to use an Intermediate Attribute. Given that the Car can have 0 or 1 mechanic (or be unknown), we could use the InstanceCount function to count the number of Mechanics working on a given Car.

OPA - Car Entity Worked On Part 2

So in the above, the Car’s workforce, a number Attribute, is used to find out the number of Mechanics working on a given Car. The other Conclusion leverages this. The result looks promising, in that the lack of a specified Mechanic gives us a “False” value.

OPA - Car Entity Not Being Worked On Debugger 2

But in the case where a Relationship is known, but there are no Mechanics assigned, such as the example below, which is obviously quite possible in a Workshop:

OPA - Car Entity Relationship Known but no Mechanic

Running our rule gives the following in the Debugger:

OPA - Car Entity Workload False Result

Clearly this is, for this contrived example, not the hoped-for behavior. After all, there is nobody working on the Car instance in this case. So our final approach might be the following:

OPA - Car Entity Relationship Final VersionWhich behaves as we would hope in the Debugger.

OPA - Car Entiity Final Result Relationship

The examples above are designed not to explain how to run a Workshop or repair your Car, rather to make you think about these useful Entity Functions. Let’s move on to another example.

We need to calculate which cars need parts to be ordered. We will base ourselves on the simple idea that cars that are older than 10 years of age, and that have nobody working on them, and that have a repair cost that does not exceed the value of the Car, will need to have parts ordered since they are not kept in the Workshop. Again, this is a spurious example for the sake of this post.

Firstly, let’s add two new Attributes to the Car Entity – the car’s residual value, and the car’s estimated repair cost:

OPA - Car Entity New Attributes

Then we can leverage the all keyword to create the following rule, with InstanceCountIf to count the number of Car instances that meet the condition.

OPA - Car Needs Parts

Finally we will highlight a further interesting example. Having calculated  the total number of cars requiring parts, let us calculate the total number of cars worth repairing per mechanic. InstanceCountIf is used in the training course ,for the purposes of demonstration, with Containment Relationships, but it is usable with a Reference Relationship as well,

OPA - Cars Worth Repairing


In our next chapter we will investigate reasoning across entities and the various functions that you can use, plus we will take a look at the French version which we didn’t have time for in this post.

OPA – Entities Adventures #4 Substitution and Screen Flows

The Workshop – Web Determinations

Returning after a brief hiatus and some much-deserved sunshine, the Mechanic and the Workshop we have built in the previous episodes (123) is ready for cars. We will begin by adding some visuals to our Rulebase to enable us to at least use the Web Determination for the purposes of demonstration, following which we will modify the Reference Relationship we built in the previous chapter.

To build a successful Web Determinatiion we need some visual stimulation. In the second part of this series we built a Screens File and created some basic visuals for adding Mechanics. Now we will add another Question Screen for Cars.

OPA - Cars Question Screen

It is for all intents and purposes structurally identical to the Mechanics Questions Screen we created earlier. But the next Question Screen is not. Add a Question Screen that asks the user to create Relationship information. For example, the below Screen is designed to let the End User tell us which Cars are being worked on by which Mechanic. This is done through a Relationship Input Control.

OPA - Relationship Entry Screen

Common Trap #7 Assuming that a Screen is going to be shown

If we Build and Run our Web Determination, ignoring the few errors regarding goals (since we have no Goal relating to the Global entity yet), we will see the following on our Summary Screen:

OPA - Summary ScreenThe Policy Automation engine is diplaying the only two goals we have right now, and they are completely independent so they show up on the Assessment Summary. Entering via the first one lets us create Mechanics. Entering via the second one lets us create Cars. But since there is no requirement in any logical sense, for there to be any stipulated relationshiip between them, the Relationship Input Control and Screen is never shown.

The Policy Automation engine sees no reason to display it – there is no goal that depends upon it. As humans we would say “but of course we need this data” but we don’t really. In the eyes of the Policy Automation Engine, “uncertain” or “unknown” are both perfectly acceptable values for the question “Who deals with which cars?“.

To force the display of a Screen, we need a Screen Flow. The idea of forcing Policy Automation to display a Screen might seem a little contrived (it is, in this case) but it can happen – information screens at the beginning of Interviews, Terms and Conditions, Confidentiality reminders and so on – and you need to display them.

Add a Screen Flow to your Project and Drag and Drop the Screens in the order shown below/. Notice that only two of our three Screens are visible, on account of the Entity value.

OPA - Screen Flow Part One

Add a second Screen Flow and complete it as follows:

OPA - Screen Flow Part Two

Then create a “Master” or “Parent” Flow, and bring them both under one Flow. Notice the selection box that allow us to add the Screen Flow relating to a Relationship.

OPA - Screen Flow Part Three


Finally add this to the Assessment Summary Screen using the New Flow button.

OPA - Screen Flow Part Four


Test your Web Determination. Observe that the Screen Flow order is followed, and the third Screen is displayed. But notice that there is a significant problem for the end user.

In our current Screen, it is impossible to see which Mechanic is being assigned which Car. Assuming I have two cars and two mechanics, I will see this twice:

OPA - Which Mechanic

Common Trap #8 Assuming Substitution will work always

In our case, “the mechanic” is not being substituted in this Screen. This is normal behavior and requires us to make use of the Public Name for the Attribute in question. In our case, we will edit the Question Screen as follows:

OPA - Substitution with Public Name Text

This will give the following, clearer output in the Web Determination.

OPA - Screen with Mechanic Name

As you have been following I am sure, we have been delivering this process using both the English and French languages. So let us look at the French version for completeness.

The majority of the work is as above, however we run into a problem regarding the Car and the entry of data when adding Car instances. The problem stems from the following:

Common Trap #9 Gender in non-English languages

In Oracle Policy Automation, an Entity is either a gender sensitive human, or an impersonal “It”. Unfortunately this is not the case in other languages. Consider the following Text Attribute, the registration of the car.

OPA - French Car Question Screen


The provided text is incorrect, since the “registration number” in French is feminine in gende. Changing the Default Gender won’t help, since instead of the “What is the …” we will get the equivalent of “Who is the registration number?”.

So we have to override the supplied text using the “Override” button and enter the text manually.

In the next chapter we will add more rules and experiment with Entity Functions, as well as modifying the cardinality of the Reference Relationship.

OPA – Entities Adventures #3 Entity Relationships…

Reference Relationships

In the previous post we laid some groundwork for our Mechanic and Car Entities. Now we are ready to implement a couple of Reference Relationships. You can think of Reference Relationships as any relationship that is not Containment – basically it is any Relationship that you create, that is not created by the Policy Modelling application.

OPA - New Relationship Step One

Create a Relationship between the Mechanic and the Car. The Source is the Mechanic, and the Target is the Car, so begin by selecting the Mechanic and right-clicking the Relationship area on the right. Enter the correct kind of Relationship, and the relevant text as shown in the example below.

OPA - Create Relationship Step Two


In this example we have created a 1-Many relationship and the text we have written reflects that in English. The text of the relationship is often used in Functions with Entities as we will see in a moment.

Relationship Type

We need to pay close attention to the type of Relationship Type, since certain functions do not work with certain Relationship Types. Let us put all of this in to practice now by adding a useful Attribute to the Car for our business logic. Add “the car’s age”  as an Attribute. Make sure that the Attribute is definitely in the correct context – note “Entity” in the top right-hand corner.

OPA - Car Age Attribute

Now we can begin to focus on the rules we can write thanks to this hard work. Let’s begin with the obvious ones. Note in the following example, that the relationship text is the function’s argument – so your text must match exactly. For the purposes of clarity I have added a new Word Document in this Project, but that is not necessary.

OPA - Function InstanceCount


Counting based on a Reference Relationship

Remember to create a number Attribute the mechanic’s workload. Creating the Attribute with the text that includes “the mechanic” ensures that Policy Modelling understands that this is an Attribute that can be applied to each Mechanic.

OPA - Add Mechanic Workload

Compare this new rule with the example we created in the previous post :

The total number of cars in the workshop = the number of all the cars 

The above rule counts cars, but all the cars. The relationship text tells Policy Modelling which relationship is the source of the information. So now, let us Build and Debug without Screens. With Build and Debug we can review and edit the data as well as save it for later use.

OPA - Add Instances of Mechanic and Car

I have added three cars and three mechanics. The only inferred Attributes that have been updated will be the orignal Attriibutes from the previous post, which leverage the Containment Relationshiip. These are populated automatically.

OPA - Global Inferred Attributes

Defining Reference Relationships

The other Attriibutes that we have just added are not yet delivering any values. Why? Because Reference Relationships will simply be “Unknown” until we actively declare which Car is for which Mechanic.

OPA - The Mechanics Cars

OPA - The Mechanics Cars Step Two

In short, these Relationships will need to be specified. If the Relationship data is “Unknown”, so therefore the Attributes that derive their value from Entity Relationship-based Functions, are “Unknown”.

OPA - Final Mechanic Count Cars


When we take a moment to select the different Cars and define their Mechanic (or vice-versa), then we get the result we are expecting. But notice that we only will see results when we have removed all  the uncertainty – in short the three Mechanics need to explicitly be defined as having 0,1,2 or 3 cars. Then the function can reliably provide the information we need.

Zut alors!

Switching to our French version, most of the behavior is identical, however the rules written using the same basic structure are less grammatically acceptable. Take the following Reference Relationship, as before, only in French.

OPA - Voitures Reference Relationship

And then the rule we build refering to it:

OPA - Reference Relationship Instance Count French

Sadly the rule is considerably less grammatically correct than the English version. It might be tempting to change the Reference Relationship text and thus be able to write a more grammatically natural rule:

OPA - Tempting Change OPA - Tempting Change 2

But it probably will just complicate matters. Even in the Debug we can begin to see that “voitures du mécanicien” without the article “Les” will probably have negative impact when we write rules later. Generally, we always should include a definite article “The” or equivalent in our Entity and Attribute so that writing rules will be more natural (there are other reasons).

OPA - French Debug with Highlights

In this case, since the Attribute “La charge de travail du mécanicien” is grammatically acceptable we can decide to make changes to the Decision Report to make it as optimally readable as possible. As we will see in the next post, where we will also add some new features to our Web Determination and experiment with Substitution.




OPA – Entities Adventures #2 Question Screens…

Back to the Workshop

So we return to our Rulebase with Mechanics and Cars. Eagle-eyed readers will see this is an adapted version of an exercise in the Policy Automation training course. The version we are using here has different relationships and attributes than the one in the course. I am not intending to copy the material used in the course.

Next Steps

In the previous post we set up our Entities and experimented wth some Containment Relationship text. Now we can begin to study our Entiities in more detail and create / edit Attributes to extend the model.

Fire up the Debugger using Build and Debug without Screens. Let’s look at the output in the Debugger. Go ahead and right-click the “all the cars” icon and choose Add Instance.

OPA - Entities Create Instance

Since the car currently has only one Attribute, you don’t have much choice as to what to enter – just double-click the green bar and type something like “Ford Fiesta”.

OPA - Create Car Instance


Which brings us to the question – just what is this information we are entering? Where did it come from, and what issues may we have?

The Attriibute you are entering was created automatically when you created the Entity definition. It is the “identifying attribute”. If this was the Mechanic, maybe it would be his or her name, or employee Id. Since it is the car, what would it be? I’ll hasard a guess and say why not the car registration plate, since it is unique and a useful way to distinguish between all those cars in the workshop. Of course our Car Entity will have a Make and Model as well, no doubt. So let us correct all of this and spot a couple of other traps along the way.

Back out of the creation and Click Build > Stop Debugging. Now double-click the Attriibute and let us review. We want this to represent the Car Registration. So go ahead and change the text. And observe :

OPA - Car Registration Identifying Attribute

Common trap #4. The Car is not a he or a she (despite what some drivers thiink!). It is impersonal – an “It” if you will. Failure to update the Default Gender will of course make for strange output in the Decision Report and Debugger.

OPA - Car Gender Error


Take the opportunity to give the Attribute a public name as well. Now we have spoken about the Car Entity, what about the Mechanic – for the Mechanic there is another one to think about.

Common trap #5 The Mechanic needs to be defined as male or female (depending on your business scenario, this may not be useful for our Rulebase, but there are many situations where it is!). To set up the “Gender Attribute” is quite simple. We have covered it before so just visit this post and resume when the Mechanic has a Gender Attriibute defined. Your Mechanic Entity should now have 2 Attributes and should look like this.

OPA - Mechanic Gender

Note that we have also edited the Attribute Text for the Identifying Attriibute since the Mechanic’s name, in our case, will be enough to differentiate between them.

The Gender Attribute will come in very handy later on in the Web Determination and Decision Report for our Rulebase, Let’s now extend our Rulebase by adding a second rule to our Word Document. Make sure you create the Attribute as a Number and that you create it in the Properties Files (that could even be common trap #5b). The creation of the Attribute will look like this:

OPA - Attribute Creation in Word Document

And the Rules should look like this now.

OPA - All the Mechanics

Now that job is done, we can begin to investigate the Gender Attribute. Firstly, we need to create a Screen File in our Project, and Create a Question Screen inside it.

OPA - Mechanic Basic Question Screen

Check your own project against the screenshot. If you are seeing “Who is the mechanic’s name?” then you need to edit the Attribute to “impersonal”, or if you chose to keep the original Attribute Text “the mechanic” then you will see that instead. Notice the new icon to show the Gender Attribute.

Build and run your Web Determination, and click the link referring to Mechanics. Add a Mechanic using the Add New Instance button.

Ignore any warnings you might get at this stage since our Interview is not really ready yet, so it has no real goals.

OPA - Create Mechanic Screen Basic

Excellent – Policy Automation has given us the two radio buttons and has shown it understands this is a Gender Attribute.

Common trap #6 Asssuming that this is going to work in different languages.

As you may know, in this demonstration sequence we have also been maintaining a parallel version in French.

OPA - French Version of Project

Having entered the different Entities, Attributes, Rules in Word and having now created the Question Screen in the Screens File, this is what we get when we run the French Web Determination.

OPA - French Mechanic Screen Basic

I’m sure you can spot the issue. To correct this we could go to the Question Screen, and the Gender Attribute Question, and change the Display Values for the List of Values.

OPA - French Gender List of Values


And so finally we get good output when we Build and Run our Web Determination.

OPA - French Mechanic Screen Basic Improved

This editing of the Display Values may come in handy of course even if you are not working in a different language. The solution to the “male/ female” issue can be found in Part Six if you can wait that long.

In the next post in this series we will get our Reference Relationships up and running. Until next time!

OPA – Entities Adventures – Setting up Entities


Entities in Policy Automation

One of the funnest parts of the Oracle Policy Automation Training which I regularly deliver are the “Entity” chapters. These chapters (sadly rather short, and positioned right at the end of the week, limiting the time we can spend on them) introduce something that most students have already guessed at long before we get there: There must be more than just creating attributes and writing rules – what happens when I have two members of the same family, or three cars, or five Service Requests….

You can insert any typical Enterprise Software entity model in the end of the phrase above. Since this is such an interesting and sometimes challenging part of the course, I thought we could have some fun looking at entity functions, attributes and so on in a series of posts.

Getting Started

So let’s set the scene : consider the following entity diagram:

OPA Cars Workshops Model Start

We will build it in the next few posts, and then extend and manipulate it in various ways to demonstrate Entity Functions and more.

So starting from scratch, let’s look at a couple of common traps to begin with.

Creating the Entities

Beginning with a new Project and a new Properties File, create two new Entities that are children of the Global Entity.

Common trap 1 : There is, in this model, no need to create a “singleton” Entity for the workshop. Any atttribute that belongs to the “workshop” can be added to the Global Entity.


OPA - Car and Mechanic Entities



Common trap 2 : As soon as you create the Entities, remember to edit the “Containment Relationship” text. If you want to create rules to count or sum mechanics or cars, then you probably want to be writing rules like this :

OPA - Total Number of Cars Long Text

OPA - Total Number of Cars Short Text




But if you go ahead and try it now, the only thing that will work is the following text, or the long version of it. The problem is the default Containment Relationshop text is something like “All instances of XXX” (where XXX is the Entity name).

OPA - Total Number of Cars with Containment Relationship Text Demonstration



So you would in this case be advised to change the Containment Relationship Text from the default as shown above, to something a little more friendly.

OPA - Containment Relationship Text Edited



Doing this right now has many advantages, not least readability, but also avoiding common build errors such as “Entity XXX is defined twice”.

If you are writing your Rulebase and rules in another language, watch out for more of the same. For example, the same Entities built in French would give us the following basic grammatical error in the standard Containment Relationship text:


OPA - Entity Model French Grammar

“Toutes les instances du mécanicien” would at least be grammatically correct, although as in English this would be unfriendly for business users. So we would change the Containment Relationship text to “toutes les voitures” and “tous les mécaniciens” –  then we could write the following rule without hindrance.

OPA - French Rule with Containment Relationship Text Edited Short Version



Common trap 3 – Never assume that in two different languages, the syntax will be correctly shown in the Function Reference. A close look in the French Function Reference gives us two versions of the InstanceCount, one long and one short, as is often the case:

OPA - Error in Function Reference FR and EN



For the purposes of comparison I have put the English and French side by side. There is an error in the French Function Reference mentioning that the Entity (ent) is the required input argument for the function, when in fact it is the Relationship Text (relationship) that is required, as correctly stated in the English version.

In the next post we will continue to work with our Entities and add some attributes and rules to the mix. Until next time.[/vc_column_text][/vc_column][/vc_row][vc_row][vc_column][vc_video link=”” title=”Entities Adventures 1″][/vc_column][/vc_row]

Logo by Southpaw Projects LLC