Category: Screen Files

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 – Screen Order and Procedural Logic

OPA – Screen Order and Procedural Logic

OPA – Screen Order, Visibility Logic and Procedural Logic

In the previous post we discussed inference, and the kind of impact it can have on the final interview experience from the point of view of the end user. That discussion brings us neatly on to another subject – different kinds of rules and when to use them. Consider a customer in a shop asking for a refund. To obtain a refund they need to provide the product they wish to return, as well as proof of purchase (a receipt), and they must have the payment card with them, and some form of photo identification. We can call that the “refund requirements” for the sake of brevity.

Rule sets will include business goal based logic such as

But for the purposes of your CRM integration, or your internal Procedural Logic, you need to log the person’s name.

The customer's name is known

What you want to avoid is mixing the two kinds of logic
OPA - Customer Business Rule The customer’s name is known and the customer satisfies the refund requirements

Although you need to know the person’s name for your own internal process, it has no real impact on their eligibility for a refund. Mixing and matching in this way is bad practice, and can end up perturbing the order that your Question Screens are displayed by the inference engine.

To overcome such a mix, you should include a new procedural goal

OPA - Customer Procedural and Business Example

One of the key questions to ask at this point of your rule creation is – does this attribute (the name) actually have an impact, or is it for statistical, commercial or other reasons? If it has a job principally of controlling data entry or interview flow, then in should be kept separate from the business rules. In the same manner, it is bad practice to use real substantive goals as part of your visibility strategy in your Question Screens. For example if you want to control whether something is going to be displayed or not on a Summary Screen, use a separate Visibility Rule.

OPA - Visibility Rule

Until next time.


OPA – The Influence of inference

Policy Automation – The Influence of inference

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

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

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

OPA - Screen Order

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

OPA - Screens File

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


OPA - Drag Drop Order Screens

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

Until next time

OPA – 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!

Logo by Southpaw Projects LLC