Category: Web Determinations

Siebel CRM as a custom Search source

Siebel CRM as a custom Search source

This post is inspired by a conversation I’ve been having over the last few days with another OPA consultant (thanks Prashil!) . Although as it turned out, the requirement had nothing to do with Siebel (that will teach me to not assume anything!), the concept of making REST calls to a CRM or CRM-like data source has been on my mind. But how can I use Siebel CRM as a custom Search source?

In this example, we will use Siebel 2018 as the source of a custom Search box. Along the way we will see how the Siebel CRM REST API sends us data and what we can do with it. At the same time, we will indulge in some trickery to not show everything we have in our Search results to the user. It will mean we create two JavaScript extensions, a Search and a Full Input.

Firstly, the Siebel 2018 instance in question is using the standard REST API, and it is the standard Component called Account which we will be querying. In many public services, Account is used to store partner organizations, external suppliers and so on. It is a very common component. The base URL for the REST calls in my case will be something like the following

https://XXXX:9001/siebel/v1.0/data/Account/Account/?fields=Name,Location&?ChildLinks=None&searchspec=([Name] LIKE '"

There are three things to note here.

Firstly I am only interested in two fields (the third field I need, Id, is actually going to be included automatically anyway).

Secondly I am using a Search Specification with Siebel standard syntax to search using the Name of the Account. So if I type “ABC”, it will look for Accounts starting with ABC.

And finally, the URL string needs to be capped with the following to finish it “*’)” so that there is a wildcard search for ABC Inc, ABC Corp. and so on. The URL also includes an argument regarding child links in the output to reduce volume.

Siebel CRM as a custom Search source

The information returned in a standard output will consist of a series of data.items. So we can iterate over the data.items and for each item, we can get the Item.Name, Item.Location and Item.Id. Since Siebel paginates its output, we are actually only going to get a maximum of ten records unless we add another URL argument and make further calls to Siebel (to get page 2, page 3 and so on). But for a query result, a ceiling of 10 is pretty good for Siebel CRM as a custom Search source.

As a side note, this example – you have noticed – is using the Siebel REST API in its unvarnished, naked form. Obviously you would do well to control / restrict access and authenticate consumers in real life. We’ve seen in previous examples that we can pass headers in our Ajax call when Oracle Policy Automation asks for data from a Search source.

In the Commit callback we will update three attributes with the values of the Siebel Fields I just mentioned. Now, at the moment, if you want to update an Oracle Policy Automation Attribute in a JavaScript extension, that attribute needs to be on the active Screen for it to work. So what happens if you don’t want to show that value to the end user, but you still want to capture it for future use in your rules?

One approach (which I am using for demonstration purposes only you understand, as usual) will be to create an invisible Input, so that we can add our data to the Screen without the user seeing it. To do this you might use a fullCustomInput extension. This is different from the customInput, because it manages the Question Text and the Input control. So we can place it on our page and format the whole thing – even perhaps make it disappear.

Siebel CRM as a custom Search sourceThe two examples working together are shown in the video below, and I have added a more appropriate fullCustomInput example, as well as the Siebel customSearch example, to the OPA Hub Shop. I am also in the process of adding them to the Template Generator, so you will be able to generate a fullCustomInput and a sample Siebel customSearch yourself as well.

Have fun with Siebel CRM as a custom Search source, and as always the official documentation is your guide.

What’s New in Oracle Policy Automation 18B #2 Relationship Control Extensions

What’s New in Oracle Policy Automation 18B #2

The main thrust of this post first came into my head when I was writing one of the recent Back to Basics posts about Relationships. And as if by magic, Oracle Policy Automation went ahead and improved the product with something I felt was lacking. I should ruminate more often, perhaps they have telepathic powers over there. So in this post, What’s New in Oracle Policy Automation 18B #2, we are going to look at the new feature of the Control Extensions : the ability to customise the Relationship experience.

What’s New in Oracle Policy Automation 18B #2

The relationship above is a good example. In the course of a prototype, I designed the car and the passenger entities for a car-sharing enterprise. A car can have many potential passengers. For each journey, however, your passenger can only be in one car at a time. And yes, I understand that I could build a many-to-many and intersection the car and passengers or infer the current passengers or what have you, but this is just an example.

What’s New in Oracle Policy Automation 18B #2

So in the above example, you can see that I am in the process of selecting the passengers for each car. Putting aside the discussion about how best to model the data, there is a challenge here. The checkbox (which is the only display offered) is fine, but due to the lack of dynamism (?) in the display, the choices remain static. I mean by that you are able to choose an incoherent selection, with the same passenger being in multiple cars.

Of course, when you do so, the engine (correctly) gives you an error and you must correct your data entry. But what if we did it another way?

The core of this is the fact that now, in Oracle Policy Automation 18B, you can use the following in your Extensions:

control.getControlType() – which now will return “OneToMany” or “ManyToMany” and so forth for relationship controls. So your code could adapt the User Experience based on the cardinality.

control.getOptions() – returns an array of the different choices for the user ( the passengers in my case above). So you can retrieve the list of choices.

To help manage this kind of extension, control.getValue() returns an array of the selected values for your relationship (the instances that have been selected). So you can examine the selected values.

Let’s look at this code. It is, as always provided for educational and entertainment purposes (indeed, many will find my stream of consciousness code amusing). It is also available on the OPA Hub Website Shop page as a free PDF download. So let’s see What’s New in Oracle Policy Automation 18B #2 : Relationship Controls with an example.


(c) 2018 Richard Napier The OPA Hub Website May 2018
Educational Example of Relationship Input Controls
I will remember this is for demonstration and educational purposes only
	customInput: function (control, interview) {
		if (control.getProperty("name") == "xPassengerSelect") {
			return {
				mount: function (el) {
					//console.log("Control " + control.getProperty("name") + " is a " + control.getDataType() + ", originally a " + control.getControlType());
					var myValues = [];
					//Previous values
					myValues = control.getValue();
					var myOptions = control.getOptions();
					//console.log("Obtained list of instances for control " +;
					var myDropDown = document.createElement('select');
					myDropDown.setAttribute('id', control.instance.toString());
					myDropDown.setAttribute('data-instance', control.instance.toString());
					myDropDown.setAttribute('data-entity', control.entity.toString());
					myDropDown.setAttribute('multiple', 'true');
					for (j = 0; j < myOptions.length; j++) {
						var myoption = new Option(myOptions[j].text, myOptions[j].value)
							myoption.setAttribute("data-instance", control.instance.toString());
						myoption.setAttribute("data-entity", control.entity.toString());
						//console.log("Added list option " + myOptions[j].text);
					for (i = 0; i < myDropDown.length; i++) {
						currentOption = myDropDown[i];
						if (myValues.indexOf(currentOption.value) != -1) {
							$("select [data-instance='" + myDropDown.getAttribute('data-instance') + "']").filter("option[value='" + currentOption.value + "']").attr("selected", "selected");
					$(myDropDown).change(function () {
						//New Values Selected
						for (i = 0; i < myDropDown.length; i++) {
							currentOption = myDropDown[i];
							if (currentOption.selected == true) {
								//Disable All Values Matching Selected in other instances
								$("select [data-instance!='" + myDropDown.getAttribute('data-instance') + "']").filter("option[value='" + currentOption.value + "']").attr("disabled", "true")
					var deselectbutton = document.createElement("button");
					deselectbutton.setAttribute("type", "button");
					deselectbutton.setAttribute('data-instance', control.instance.toString());
					var deselectbuttontext = document.createTextNode("Deselect All");
						function () {
						$("select [data-instance='" + this.getAttribute('data-instance') + "']").filter(":selected").prop("selected", false);
							$("select [data-instance!='" + this.getAttribute('data-instance') + "']").attr("disabled", false);
					for (i = 0; i < myDropDown.length; i++) {
						currentOption = myDropDown[i];
						if (myValues.indexOf(currentOption.value) != -1) {
							$("select [data-instance='" + myDropDown.getAttribute('data-instance') + "']").filter("option[value='" + currentOption.value + "']").attr("selected", "selected")
				update: function (el) {},
				unmount: function (el) {}

So what are we looking at. There are probably four key areas in this rough prototype.

Lines 18 to 27 build a multiple-select drop-down instead of the check-boxes. Using HTML 5 data attributes, each option and each drop-down (there will be  drop-downs, one for each of the car ) is tagged with the instance name and the entity name. This is useful if you intend to have a page with lots of entity-related things on it , and it was useful in the Entity Collect example from a few weeks ago as well.

Lines  29 to 33 look through the existing values of the Control (maybe the user has already been working on this page, and has now come back to it for further editing) and selects programatically all those values that were chosen previously. Otherwise when you click the Next button and then the Previous button, you will no longer “see” your selections even though they actually have been selected.

Lines 38 to 58 handle the Change event if the user selects other items in the multi-select, and ensures that the corresponding items are deactivated in the other drop-downs.

Lines 58 to 78 create the Deselect All button for each drop-down, which removes all the selected items both from the drop-down and from the underlying control values, and re-enables the values in the other drop-downs.

Once again, I state for the record that this was just a “stream of consciousness” which became a bare-bones prototype. There are lots of holes in the code, and lots of repetition because I just wrote it in a single shot. So you have been warned.

It does, however, demonstrate the new functionality, so our post title What’s New in Oracle Policy Automation 18B #2 is fulfilled. This is something you could not really do in previous versions.

Have fun!

Guest Post : The Lazy Expert – Oracle Policy Automation Public Cloud with Oracle Service Cloud Part 2

The Lazy Expert -Oracle Policy Automation Public Cloud with Oracle Service Cloud Part 2


We are continuing our Lazy Expert series of posts, with an explanation of how OPA Public Cloud, and the rulebases deployed there, can be used within the Oracle Service Cloud application. In case you have missed out on our first port of this series, you can find it here. With the right Nudge, our Lazy Expert is not so lazy after all. If you are missing the original post about the lazy expert, here it is.

Part 1  looked at exploring, deploying and verifying the”RightNowSimple” rulebase to work with your Service Cloud Connection. The rulebase was launched directly using the Interview Session URL. In this post, we will be looking at embedding this Interview into the Consumer Portal of Service Cloud so that anonymous visitors to the portal can use this same interview in self-service mode. This is accomplished by publishing an “Answer”, with Interview Session URL embedded in an IFRAME, to the Consumer Portal.


  1. Steps in Part 1 are completed and the Service Cloud Connector is verified to be working as expected.

Publish the “Answer” to Service Cloud Portal for anonymous use

In our simple example, we are going to embed the interview from Oracle Policy Automation as a publicly accessible page in a mythical “portal” website. Customers will be able to browse the website without in any way identifying themselves – anonymously.

  1. Create a new “Public” Answer in Service Cloud as shown below.
  1. In the Answer Tab, Source Sub tab, specify the content using an IFRAME tag as shown below.

The IFRAME tag is of the format

<iframe height="580" src="https://server/path/web-determinations/startsession/RightNowSimple" width="100%"></iframe>

where the “server/path” should be replaced with the values appropriate for your Oracle Policy Automation Cloud environment.

Oracle Policy Automation Public Cloud

  1. Save the Answer record. Make sure that the Answer you have created was using Source mode, otherwise your IFRAME will not display properly.

Verify the results in Oracle Service Cloud Consumer Portal

  1. Search / Navigate to the Answer record in the Consumer Portal, as an anonymous user using the keyword or text that you entered when creating the Answer above.
  2. View the details of this Answer and work with the Interview Session as normal. The result will be the same – the Contact is saved in your Service Cloud instance.

Oracle Policy Automation Public CloudSummary

This post explains how the benefits of an OPA rulebase and the corresponding Interview experience can be made available for anonymous users using the Service Cloud Consumer Portal. Check this space when we will continue next with part 3 of this series that focuses on embedding such interview sessions into the Consumer Portal of Oracle Service Cloud for known contact users…


Renderer – Siebel & Oracle Policy Automation 12

Renderer – Siebel & Oracle Policy Automation 12

Note: This article is a cross-post from my other “Home” the Siebel Hub. It addresses both Oracle Policy Automation and Siebel, so I figured I should post it here too.

One of the more fascinating elements of the recent 2015.5 release is the arrival of a new Applet renderer in the Open UI universe. This particular renderer is used for the integration with Oracle Policy Automation 12 (August 2015 and beyond) for private cloud customers. To complete the picture, there is also a new Presentation Model. But in this article I want to focus on the interesting way the renderer is used.

Old Style

In Oracle Policy Modelling, we design our own Web interface, for example for deploying an online process of assessment for benefits. If the resulting Oracle Policy Modelling rulebase is going to be used in Siebel (either as well as the standalone Web version, or as well as), then traditionally we have had only two ways of integrating it with Siebel Enterprise:

  • Embed the Web page with a Symbolic URL
  • Deploy the Policy as a Web Service of one kind or another

The Symbolic URL worked nicely but had the usual weakness – the user interface looked different to Siebel:

Renderer - Siebel & Oracle Policy Automation 12 - OPA Version 10 Rulebase in Web Determinations

The Web Service worked nicely but had no user interface – just a SOAP request and response. Lots of work.

Of course you could launch yourself into a complete Java or C++ experience and create new clients to consume either form of Web Service, but you would be looking at a considerable amount of development.

New Style Renderer – Siebel & Oracle Policy Automation 12

But now thanks to a new Policy Modelling UI and a new Siebel Open UI PM and Physical Renderer we have another option – map the Oracle Policy Automation Web experience to the Siebel Open UI engine, and let the JavaScript API do the work of displaying our Policy Modelling UI, transformed into a dynamic Siebel experience.

In concrete terms, Siebel can now “display and run” the Oracle Policy Automation Web assessment as a typical Siebel Applet.

Maybe you have two Policy assessments, and they both have completely different questions and User Interface (perhaps one for Housing Benefit, the other for Disability Benefit) – does that mean we have to create Applets for each Policy Modelling Rulebase?

No, it doesn’t, thanks to the magic of the integration and the related Open UI JavaScript API used by the new Presentation Model and  Physical Renderer. Policy Automation Interview Screens built in OPA can now store Siebel control information which will be passed to Siebel through the provided integration layer (HTML Templates for the layout, Workflows and Business Services / VBC for the rest).

Since Siebel does not maintain / persist data for each of your Policy Automation Screens, but gets it dynamically as the user presses the “Next” or “Back” button in the Policy Web experience, the Presentation Model and Physical Renderer of the Siebel Open UI Framework needs to be able to display the different layouts on the fly, so to speak.

Templates to the rescue!

The layout is built by preparing static HTML pages that contain the different Screens of your Policy Modelling user experience, and then we get Siebel to display and manage these dynamically. Look out for a bunch of Siebel Open UI files entitled “dyna*.js” in a manifest near you, and look in your LANG folder for /htmltemplates.

Simply Put

There is one View, OPA Interview Service View, that is used to render all your different Policy User Interface experiences. It must render dynamically the Screens and Controls defined in Oracle Policy Modeller.

The Oracle Policy Modeler uses custom properties to define mappings to Siebel controls like Labels, Textboxes, Images and more. The Business Service  Dyna Frame UI Service with it’s Method called BuildDynaFrame in Siebel Enterprise takes care of dynamically displaying the HTML template, merged with the actual questions being entered or being seeded from Siebel. The Applet used is driven by the OPA Integration VBC.

The steps to put this together might look a little like this.

How it Works

  • Create the Oracle Policy Model and associated UI in the Modelling application. Nothing new here, except for the new, easier to use editor in Policy Modeler 12.

Renderer - Siebel & Oracle Policy Automation 12 - OPA Integration Step One

  • Add Siebel control and HTML information in the Modelling application. Notice that we reference a template, and HTML IDs that are going to be in our HTML template.

Renderer - Siebel & Oracle Policy Automation 12 - OPA Integration Step Two

  • Create or modify an existing static HTML page that has the corresponding tag names as seen in the previous step. Upload this file to LANG/htmltemplates/something.

Renderer - Siebel & Oracle Policy Automation 12 - OPA Integration Step Three

  • Add configuration information to the Siebel OPA Mapping View to inform Siebel of the exact Policy Rulebase to be executed in the different situations, and provide other configuration data such as whether data is seeded from Siebel, and so on.

Renderer - Siebel & Oracle Policy Automation 12 - Opa Integration Step Four


  • Configure a button to launch the Policy Rulebase from Siebel Enterprise. Note the page below is from the Public Sector Self-Service application (aka pssservice_enu)

Renderer - Siebel & Oracle Policy Automation 12 - OPA Integration Step Five

  • Observe the result when you click the button in the Siebel UI, displays your HTML template in a dynamic frame, with the Oracle Policy Automation controls mapped to Siebel controls

Renderer - Siebel & Oracle Policy Automation 12 - OPA Integration Step Six

This is what the original rulebase looks like in Policy Modeler, with the same layout and controls.

Renderer - Siebel & Oracle Policy Automation 12 - OPA Integration - Rulebase in Version 12 Debugger

You can find some information about all this in the Public Sector eService Open UI PDF of the Siebel Bookshelf.


The underlying drum-beat is getting louder and louder. Siebel and OPA are getting closer and closer. It will not have escaped your attention that Siebel IP2015.5 shipped with this integration, nor will you have failed to notice that the Siebel Mobile 2.0 comes with OPA included as an optional extra:

Renderer - Siebel & Oracle Policy Automation 12 - OPA Siebel Mobile

Renderer – Siebel & Oracle Policy Automation 12

The noise is getting louder and louder – had it escaped your notice that there is a recent Oracle presentation called “OPA in Every Industry“? Be ready for the OPA Revolution – coming soon to a Siebel near you.


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