Welcome to the OPA Hub!


Category Archives: Custom Control

Oracle Policy Automation – JavaScript Custom Options

Oracle Policy Automation – JavaScript Custom Options

Following on from the occasional series of posts that has dealt with  Oracle Policy Automation JavaScript Custom Labels and Oracle Policy Automation JavaScript Custom Search extensions, this short post is going to demonstrate how to use the custom Options extension to build an Oracle Policy Automation – JavaScript Custom Options example. The scenario is very simple, and can mostly be achieved using non-JavaScript functionality but the goal is to showcase the capability. You will need to imagine your own business requirement.

Let’s get started. In a simple Oracle Policy Automation Project I have three attributes : the Country, the Town and the Town Level. In each Country, there are a certain number of Towns. These can be considered as a dynamic list for the purposes of our demonstration. They will be stored in an Array of Objects. They could, naturally, be obtained from a REST call to some service or other, much like the example of Search Extension. For our purposes we will have only four towns per country. Each town has a level, which corresponds to its population size.

When the user selects a Country and Town Level, we will display in a Custom Options list, the Towns that have the same Town Level or higher. So if you choose level three, we would like to see towns of levels one, two and three. If we choose level two, we would like to see levels one and two in our Oracle Policy Automation – JavaScript Custom Options list. We wish to display them as radio buttons.

Oracle Policy Automation – JavaScript Custom Options Example

How can we achieve this goal:  here is the example in more detail.

The User Interface is prepared according to the following screenshots:

Oracle Policy Automation - JavaScript Custom Options - Setup CountryThe above shows the first Screen.

Oracle Policy Automation - JavaScript Custom Options - Setup Options Extension

The second Screen displays the future dynamic Options. Note how it is a simple Textbox.

Oracle Policy Automation - JavaScript Custom Options - Code Introduction

In the above image, the basic setup is performed. Values of the Country and Town Level are acquired. An empty Array of towns is created.

Oracle Policy Automation - JavaScript Custom Options - Code Array Creation

The second part of the code is too long to reproduce here, but the above image will give you the idea. According to the Country, the array of Town objects is built. Note the text and value properties which are required, and I have added a level property. I have also, of course, created an alternative set of towns for Ireland (but I won’t show it to save space). Now I will filter the array based on the town level chosen:

Oracle Policy Automation - JavaScript Custom Options - Code Return Array Filtered

In this final screenshot, you can see the filter is based on the level and the filtered array is passed out. In addition I have specified the display as radio buttons.

Oracle Policy Automation – JavaScript Custom Options Result

Executing the code in the Project we can see the following when we select the country as Ireland, and the town level as 2, for example:

Oracle Policy Automation - JavaScript Custom Options - Result Example One

In the same vein, when France is chosen, and town level 1, this is the result:

Oracle Policy Automation - JavaScript Custom Options - Result Example Two

Have a nice day! If you would like a copy of the example code and Oracle Policy Automation – JavaScript Custom Options Project, just leave a comment to that effect. As always the official documentation can be found on the Oracle website.

How Oracle Policy Automation Is Helping Shape the Future of Customer Service [BRK1030]

How Oracle Policy Automation Is Helping Shape the Future of Customer Service [BRK1030]

There is a strong argument, as a consultant and trainer, for always attending this kind of breakout. The goals of this Oracle Policy Automation presentation were quite straightforward but very difficult to achieve within a very short timeline.

  1. Explain what OPA is
  2. Demonstrate how much of a game-changer OPA is
  3. Showcase customers who think so too
  4. Explain what is coming up in the product road-map

It was also, for me personally, an opportunity to meet with people I usually only get to communicate with electronically (in this case Davin and also Len who serendipitously was in the line to speak with Davin), and of course a good way to gauge the audience – is OPA picking up speed?

The event started with a two stage overview : first the product architecture :

Oracle Policy Automation

Then a canned video demonstration. But the best part of the demonstration was the payoff at the end. Having shown us a neat business scenario in the video, Davin then proceeded to live demo most of the content from scratch : an awesome way to showcase just how business-friendly Oracle Policy Automation really is.

In the second part of the presentation, Davin showed how some major organizations are using OPA:

In the last part of the presentation, Davin lifted the lid on a few of the changes coming up in the next versions (Safe Harbor Applies) which included the following interesting titbits:

The points that tickled my brain most were :

Inspections in the Mobile App – the ability to see a list of interviews to execute and then synchronize when back online. Healthcare visitors will be very happy with that.

Browser-based : Although businesses love the high-impact nature of Word and Excel and the Modeler, it would be very cool to have the option to work on Rules without them.

I had the chance to ask Davin for more information about Interviews in Siebel, Custom Controls and more. I was very happy he took the time to share all that with the OPA Hub Website, so without telling you too much (otherwise I might have to …).

  1. A Roadmap for Siebel and Oracle Policy Automation Interviews without the constraint of an IFRAME [ooooooh!]
  2. A Roadmap for Oracle Policy Automation Custom Controls and JavaScript better managed and organized and encapsulated [ooooooh!]

Of course these nuggets were all under the Safe Harbor statement so we shouldn’t make assumptions or calculations based on these but as time goes on we can watch out for news on these fronts.

Oracle Policy Automation OPA 12 Browser Detection

Oracle Policy Automation OPA 12 Browser Detection

Oracle Policy Automation OPA 12 Browser DetectionI wanted to go back over a situation I had a couple of weeks ago, in respect of needing to detect the user agent of the Browser that had an OPA 12 IFRAME in it, for reasons I will describe in a moment. As many of you know, the latest versions of Oracle Policy Modeling are moving away from the concept of bundling JavaScript files and other externals (such as CSS Files) with the Project by means of the /interview-theme/resources folder. In fact in the latest versions in “latest version” mode there is no support for JavaScript or CSS added by this mechanism, nor by Custom Control. So “August 2016” mode to the rescue when it comes to OPA 12 Browser Detection.

We could either just drop the JavaScript and CAA in the resources folder above, or in the case I met this week, this was not an option, it had to be a PHP file thus it was a Custom Control.

Putting aside the questions like “Where is OPA going with support for JavaScript?” (which would seem to point in the direction of RuleScript) it brings to the fore the need to achieve certain things – like browser user-agent detection – within the now somewhat less flexible framework. Let’s look at what I am talking about.

Internet Explorer 11 and the IFRAME : OPA 12 Browser Detection

Internet Explorer 11, especially in Windows 10 and on Surface tablets, behaves differently from the majority of browsers (why is this not a surprise?) in respect of opening PDF files from within an IFRAME. The PDF file is not displayed, an error is logged in the console and (in the case of Oracle Policy Automation) the session is lost.

So one obvious approach would be to prepare two links, one to download the PDF and another to open the Oracle Policy Automation Form in, for example, HTML format since that is not subject to the same security block. And then, depending on the browser user agent, hide one of the links so for the end user it is totally transparent:

  • For IE11, display the HTML version of the OPA Form
  • For all other browsers display the PDF link to the OPA Form

The advantage of this approach is improved maintenance – there is only one form, just two delivery mechanisms. Now we need to show or hide the relevant link depending on the browser.

Getting the User Agent : OPA 12 Browser Detection

Now we are faced with the User Agent issue. As you probably know, Custom Controls in PHP are still supported or at least functional as long as it is an Oracle Policy Modeling Control of type Label and your Project is set to “August 2016 mode” . So this is how we might proceed. If we use a Custom Control in PHP, the $_SERVER[‘HTTP_USER_AGENT’] variable will contain the User Agent ready for use in PHP. But it will probably return a value that is not that serviceable or even correct. But the advantages of being able to access the $_POST array (with all of the interesting metadata and things in it) mean that sometimes PHP is the way you need to go.

PHP Version : OPA 12 Browser Detection

So, JavaScript via PHP to the rescue (and yes, I know there are other ways of doing this, but I just want to illustrate a problem and point you in one direction for a solution, even if it perhaps sits right on the edge of server / client code separation). Here is a sample PHP snippet which you can attribute to a Label Custom Control. Host the PHP on your web server or wherever you have PHP.

Notice the “Trident” match : as a simple demonstration I used the text string “Trident” to detect IE11. It is not meant to be a completely bulletproof detection just an example to be replace which whatever string you are looking for. For reference I include the HTTP User Agent reported by PHP versus the JavaScript navigator.userAgent.

<?php
echo '<div style="display : none;" name="ode_browser_check" id="ode_browser_check" class="ode_submit" >' . $_SERVER['HTTP_USER_AGENT'] . '</div>';
echo "<script type=\"text/javascript\">
var myData = navigator.userAgent;
if(myData.match(/Trident/i) )
{
 (function($) {
 $(document).ready(function(){
 $(\"#id_tohide\").remove();
 $(\"#id_toshow\").show();
 $(\"#id_ofcontainerdiv > a\").attr(\"target\", \"_blank\");
 });
 });
})(jQuery);
} else {
 (function($) {
 $(document).ready(function(){
 $(\"#id_tohide\").remove();
 $(\"#id_toshow\").show();
 });
 });
})(jQuery);
};";
echo '</script>';
?>

The example above assumes you have two HTML IDs, one for the link to hide, one to show. If you are using the standard OPA Form link, you will need to add the “_blank” target to the link that points to the HTML output version, as in the example otherwise IE11 will open it in the same window and you lose your session. With these tags and code in place, your IE11 users will see one link, the other browsers will see another link.

JavaScript Version : OPA 12 Browser Detection

If you are in a position where a JavaScript file is all that is needed then you can do pretty much the same thing of course just by reverting to normal JavaScript syntax.

if(navigator.userAgent.match(/Trident/i) )
{
 (function($) {
 $(document).ready(function(){
$(\"#id_tohide\").remove();
 $(\"#id_toshow\").show();
 $(\"#id_ofcontainerdiv > a\").attr(\"target\", \"_blank\");
 });
})(jQuery);
} else {
 (function($) {
$(\"#id_tohide\").remove();
$(\"#id_toshow\").show();
 });
})(jQuery);
}

Note : All of the above will, by definition,  not work in “latest version” mode since Custom Controls / JavaScript  are not supported in “latest version” mode.

Note : In light of all of this, it makes me wonder how much longer Oracle Policy Automation deployment on a website  or on Oracle Service Cloud Customer Portal or Agent Desktop, can depend on such a nasty, legacy HTML tag as the IFRAME.

Have fun.

OPA 12 - Add Label Custom Control

OPA 12 – Interview Screen with no Buttons

OPA 12 – Interview Screen with no Buttons

A colleague asked me an interesting theoretical question about an Interview Screen with no Buttons last week. Much of the detail I will skip and just get right to the things that he was adamant about!

  • He wanted an interview with a single Screen
  • He wanted an Interview Screen with no Buttons
  • There should be no JavaScript
  • The conclusion should auto-calculate when the data is entered

We all love a challenge don’t we? So the objectives proved to be by and large achievable, although for the final point my solution was not at first accepted, but with a bit of arm-twisting it passed muster. So let’s look at the steps to bring this to fruition, in a simplified case.

I first create my Project in Oracle Policy Modeler and then add my rules. In this case, since there was a mathematical calculation involved, there really was, from the user perspective, one answer to be obtained. Asking the user to click a Submit button did feel a bit like overkill.

After adding all the requisite parts to the (only ) Interview Screen with no Buttons, we have something like the following screenshot:

OPA 12 - Single Screen Example Interview Screen with no Buttons

And the Debug session will provide the following, utterly non-interactive output:

OPA 12 Single Screen Debug Interview Screen with no Buttons

Assume for the case in point that the two inputs are the drivers of the goal. The goal, which was placed on the only Screen in the Interview editor above, never displays since there is no button. You cannot go forward or backward or submit or anything else. Since it is the first and the last Screen, no buttons are allowed anyway. And my colleague said no buttons!

So what’s the answer?

Add a custom control, that contains only HTML (no JavaScript, remember!). The custom control is just a snippet of HTML that looks and feels just like an OPA button, but is invisible. The custom control is required since the HTML button tag is not white-listed by OPA, so if you try and add the HTML tag to your interview Screen manually, you will get an error. But as a custom control, no problem. Upload the custom control to your favorite Web Server.

opa-12-single-screen-custom-control

Plant a label on your Interview Screen and edit it so that it is using your Custom HTML file, as shown in the two steps below. Remember that you first add the Label, then you change “Normal” to “Custom” in the Ribbon. Please note that inline styling like that style=”display : none !important;” HTML attribute is not a good idea, but I did it here for the sake of brevity.

OPA 12 - Add Label Custom Control Interview Screen with no Buttons

So now we have a form, with a Submit button. And you can probably guess what is going to happen when you run the Interview in the Debugger. Our Interview Screen will display as before. But this time, enter some data in the Input boxes, and press Enter when you are ready to get the answer. The Interview Screen behaves just like an everyday HTML form and the Enter key submits the form, the Submit fires and we get our answer.