Welcome to the OPA Hub!


Category Archives: Web Determinations

Siebel CRM as a custom Search source

Hi There!


This content is accessible only to logged in users of the OPA Hub Website.

To Register takes only 10 seconds and uses LinkedIn for authentication.

Once registered you can change your OPA Hub password and manage it independently of LinkedIn.

We recommend you keep different passwords for all your sites.

To register, click the Log in link in the menu at the top of your page.

Thanks, the OPA Hub Website.

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.

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
49
50
51
52
53
54
55
56
57
58
59
60
61
62
63
64
65
66
67
68
69
70
71
72
73
74
75
76
77
78
79
80
81
82
83
84
85
86
87
/*
(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
 */
 
OraclePolicyAutomation.AddExtension({
	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 " + control.id);
					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());
						myDropDown.options.add(myoption)
						//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) {
								myValues.push(currentOption.value);
 
								//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");
					deselectbutton.appendChild(deselectbuttontext);
 
					el.appendChild(myDropDown);
					$(myDropDown).after(deselectbutton);
 
					$(deselectbutton).click(
 
						function () {
						$("select [data-instance='" + this.getAttribute('data-instance') + "']").filter(":selected").prop("selected", false);
						control.setValue("");
							$("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

Introduction

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.

Pre-requisites

  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.

Summary

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.

R@ichard

OPA – Entities Adventures #3 Entity Relationships…

Hi There!


This content is accessible only to logged in users of the OPA Hub Website.

To Register takes only 10 seconds and uses LinkedIn for authentication.

Once registered you can change your OPA Hub password and manage it independently of LinkedIn.

We recommend you keep different passwords for all your sites.

To register, click the Log in link in the menu at the top of your page.

Thanks, the OPA Hub Website.

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.

Entities Adventures 1