Oracle Policy Automation OPA 12 Browser Detection

I 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.