Welcome to the OPA Hub!

Tag Archives: Interview

Custom JavaScript Extension Places and Custom Options List

Custom JavaScript Extension Places and Custom Options List

This is the last in the series of posts about Google Maps and Oracle Policy Modelling for now. I’m conscious of the fact that there are lots of people out there who have more knowledge in JavaScript than I have, so I don’t pretend to provide anything more than “sketches” or “ideas” or “rough hacks”. But I hope you enjoy them anyway. This last post is all about a Custom JavaScript Extension Places and Custom Options List. We will use the basic principles of the previous examples and extend :

  • Display a Map
  • Geocode and Mark
  • Show an Infowindow
  • Find places in a certain radius
  • Display them in a Custom Options list

And this time we will use the Places API to get a list of information from Google, before displaying it in the Screen and using the information. Here is the scenario:

  1. You have a problem (fire, accident, police or flood or what have you)
  2. You are at a specific location (geolocalised)
  3. You need a list of people who can help (for example, a list of car repair workshops, or fire stations, or whatever).

This might fit into the scenario of an assistance company which wants to help you, by pointing you to the nearest garage or hospital or whatever. This uses the Google Places API. When you search it, you get a list of places – garages, hospitals or whatever. You set the starting location, define the radius in metres, and the type of search. The results come back as a list of places, which you can parse and add to your Oracle Policy Modelling screen as a Custom Options list.

So here is the lowdown.  The key to the Places search is in the request, as shown below:

var latlngnew = {
 lat: interview.getValue("cl_lat"),
 lng: interview.getValue("cl_long")

var request = {
 location: latlngnew,
 radius: '50000',
 type: [interview.getValue("cli_search")]
 var service = new google.maps.places.PlacesService(map);
 service.nearbySearch(request, callback);

In the example above you will note that there is an Oracle Policy Automation attribute value to define the type. For example, the “accident” option in the first screen:

OPA 12 - Custom JavaScript Extension Places and Custom Options List 1

Google Maps API Places Search uses type to distinguish what to look for. The mapping I made is just for fun, but bear in mind you might not find a single type that meets your needs, or you might not find any kind of match at all. The 50,000 is the number of metres for the search radius. You might get that from another attribute in Oracle Policy Automation, of course. Plus of course, there are the two attributes in which we have captured the latitude and longitude sent by the Browser.

In the callback function, we receive (hopefully) some results for our Custom JavaScript Extension Places and Custom Options List. The results are tidied up a bit, since the Oracle Policy Automation Custom Options Extension wants text and value properties (in case you want to have display values that are different from the actual values that will be stored in the receiving attribute). Finally the result is passed to the interview.

Custom JavaScript Extension Places and Custom Options List 2

Over in the Custom Option JavaScript file, we just need to grab the data from the Places API and display it as a searchable combo.

OPA 12 Custom JavaScript Extension Places and Custom Options List 4

So the end result of our Custom JavaScript Extension Places and Custom Options List exploration is that the list of providers displayed is based on the type of problem, and the location of the device. So hopefully the list of suppliers / fire stations / hospitals / police stations or whatever is pertinent.

As usual the very unpretty code, for entertainment purposes only, can be downloaded from the OPA Hub Shop. The next few blog articles are going to be on very different subjects than the JavaScript extensions, but I’m sure we will come back to these concepts often. Have a great day!

NB : Remember to test this using your favourite real Browser, not the embedded Browser : run the Debug with Ctrl+F5.

Siebel Symbolic URL and OPA

Siebel Symbolic URL and OPA

Last week I was working on Oracle Policy Automation integrated with Siebel. As part of the implementation one of the Oracle Policy Projects is going to be displayed in a Symbolic URL. If you are not a Siebel person, then this is a mechanism to pass arguments to a base URL using an Administration screen. Typical arguments might include the window size, the SSO characteristics and other disposition information.

The reason I mention it here is because the Oracle Policy Automation project had several input attributes mapped to URL arguments. It is worthwhile knowing and remembering that the manner in which Oracle Policy Automation handles these arguments is different to the standard way that Siebel does it.

From the documentation we learn that input attributes thusly mapped are to be provided in one of two ways. The choice depends both on the desired approach and the number of attributes.

  • startsession/ProjectName?seedData=argument%3dWord%20SecondWord

The above method is passing one argument. The URL is encoded.

  • startsession/ProjectName?seedData={name:Word%20SecondWord,assessment_date:2017-01-07}

This second example has two arguments, and uses a JSON snippet. This format allows for multiple input arguments. The principle reason for speaking about these two concepts is that Siebel Symbolic URL tries to code the URL by default. So if it is already coded as above you might get some odd results.

If you are using Siebel therefore you will need to add the following Field to your Symbolic URL definition in Siebel. The EncodeURL command takes a Boolean value so you try and set it to False.

Have a nice day.


Oracle Policy Automation May 2017- CORS

Oracle Policy Automation May 2017 – New Features #5

Oracle Policy Automation May 2017 – New Features #5

In every release of Oracle Policy Automation there are stand-out features. Already in this series about Oracle Policy Automation May 2017 we have seen so many great features :-

  • PDF Templates for Forms
  • Dynamic List Values
  • Styling via The JavaScript Extension API
  • Control Extensions via The JavaScript Extension API

For this, the fifth post in the series about Oracle Policy Automation May 2017 we have definitely arrived at a major, triumphant upgrade in functionality. Finally we are able to embed our interviews without the use of the hated IFRAME tag. For too long we have been stymied by the use of an outdated, unresponsive and frankly quite horrible tag to get our great interviews into existing website content. The JavaScript extension that we looked at in videos three and four in this series once again comes into play, and using a simple technique redolent of jQuery we embed the interview in a DIV tag.

To accompany this new feature we also have two pieces of required infrastructure : firstly the style sheets and JavaScript files to support the embedding, and secondly the new administration feature in the Oracle Policy Automation Hub, whereby we can add the required external sites to our “Authorized” list, thereby removing Cross Origin scripting issues from the browser and ensuring the functionality works smoothly.

Oracle Policy Automation May 2017- CORS

In the video that accompanies this article, you will discover the basic structure of an example HTML file, observe live debugging and updating of the “Authorized” list and lastly you can watch my jubilation as the interview kicks off in my embedded DIV without a single IFRAME in site. I look forward to helping my clients move away from the various hacks and other cosmetic touches to hide an IFRAME to a more modern, JavaScript extension-based approach.

For more videos you can check out our Video Gallery. The other posts in this series concerning Oracle Policy Automation May 2017  are parts 1, 2, 3 and 4.

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.

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($) {
 $(\"#id_ofcontainerdiv > a\").attr(\"target\", \"_blank\");
} else {
 (function($) {
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($) {
 $(\"#id_ofcontainerdiv > a\").attr(\"target\", \"_blank\");
} else {
 (function($) {

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.

Combining Siebel IP 2016 and native OPA 12.x Interviews + Answer Service (Updated)

Combining Siebel IP 2016 and native OPA 12.x Interviews + Answer Service (Updated)

Well, the files are now available : The official Oracle Policy Automation Blog has corrected the links and you can download the files without incident. As I had cause to use them this week, I thought I would provide some feedback on them and highlight some things that might be useful.

Firstly, I appreciate (massively) the hard work that has gone into preparing something like this. I know it is a lot of effort and I am really grateful. The document was however designed for native OPA 12.x and Siebel platforms which have been on an upgrade path, so there are some things which are assumed to be present which might not be in some cases. For example, my own :). I was installing a brand new instance of Siebel IP 16 and OPA 12 February 2017 Hub for the purposes of a prototype.

The document itself is pretty good – but some bits could have done with  a spell check. I’ve worked with Siebel and OPA for a long time, but I have never had to “stimulate a Workflow” in my life. I would probably get arrested for it anyway. Here are some other things I noticed.

  • The SOAP action pattern on page 8 does not require the ‘quotes’ that are included.
  • The Tables for GetCheckPoint and SetCheckPoint do not exist on a brand new Siebel 16 installation (the decision report tables)
  • The SoapUI Project that is included will fail to import because of a missing WSDL – which is no big deal since by then you have your own – but you will probably have to then compare all the namespace prefixes in your WSDL and edit the requests to match.
  • If you have a new Siebel platform, you will need to add the relevant EAI File System Permissions to save files in c:\temp
  • You will need to change (at least on Windows 2008 R2) the file paths to have a single backslash, not a double backslash
  • Mention is made of “three DLLS” that may be referenced in an error when you try and simulate the Workflow Process. For reference, since they are not listed in the document, they conform to the pattern  “ssopa*.dll”.
  • One of the imported Workflow Processes has both a completed and an in progress version. The in progress version has an error in it, so don’t be tempted to publish and activate unless it is the previous version.
  • Unless I am going completely mad, the main OPA Submit Workflow Process on page 12 has an error in the last step “Read from File”. The file name referenced is not referenced anywhere else, in the entire repository – and it causes an error since the file does not exist. Editing the properties to match the file name used earlier in the Workflow Process causes the error to go away.

  • When you are compiling all the imported objects, don’t forget to compile the Symbolic String project (since the WD Launch button has a Symbolic String that has been added). I know that the PDF says to do a full compile but if you are just mounting a test platform, you want a quicker way. Plus, if you do an incremental compile, watch out for errors afterwards with PickList Repository Business Object in Siebel Tools. You might need to drop the freshly compiled SRF into the Server, Client and Tools installation folders.
  • The Eligibility OPA Project found in the Siebel 16 example folders does not upgrade to February 2017 – the mapping of the data types fails when trying to use the generic Siebel Connection example demonstrated. The Value Lists are causing the problem. Although it wasn’t part of the scope of the document, if you are setting up a new environment you probably want to show the Answer integration with the HTML / XLST / Custom Properties that was used in Siebel IP 15 for comparison purposes. The Screening example works however.
  • Finally, and this I found quite frustrating, after all the work I notice that the Save Workflow – that updates Siebel after the interview – has a hard coded save of only one piece of information in it. As far as a demonstration of generic approaches is concerned, could do better.

I will make the SoapUI adjusted / completed project for native OPA 12.x available in a few days once I have time to tidy it up – it might save you some time. Other than that did you find any issues with this native OPA 12.x integration into Siebel IP 16?

Combining Siebel IP 2016 and native OPA 12.x Interviews + Answer Service

Combining Siebel IP 2016 and native OPA 12.x Interviews + Answer Service

The Oracle Policy Automation official blog came alive last week with it’s first post in over 6 months. This post, which included a white paper and a zip file of Siebel-related configurations (see my remarks at the end of this post), raised the topic of Oracle Policy Automation 12 with Siebel 16. The simple facts are, that the Siebel release cycle does not keep pace with the Oracle Policy Automation release cycle, at least in the domain of the integration with Siebel Open UI.

As you may already know, the previous major releases of Siebel Open UI (2015, then enhanced in 2016) introduced the concept of a “seamless” integration with Oracle Policy Automation. It required the following to be configured:

  • Mapping Oracle Policy Modeling Screens to Siebel Open UI Controls via static HTML files stored on the Siebel server, and a set of Siebel Workflows to handle the mapping and XSLT.
  • Exposure of the Siebel Web Service to the Oracle Policy Automation Hub Application via the Connections tab
  • Managing the different service calls via various Interview-based Siebel Workflows

Unfortunately, at the time of the release of this solution, not all Oracle Policy Modeling Interview Controls were supported (notably the Container and the Image Control were missing). Since that time, Oracle Policy Modeling has added further enhancements in both November 2016 and February 2017 releases (lots of new controls, better checkpoints) . The integration with Siebel therefore had lost further ground. It is not surprising therefore to see the proposal of a new solution supporting more features,notably more controls and checkpoints.

I had hoped to provide you with a demonstration, however, the two files linked in the article both respond with 404 errors. I have posted a request to have that seen to, and will report as soon as I can on Siebel integration with Oracle Policy Automation.

Boolean Values – Getting Started with Oracle Policy Modeling

Boolean Values – Getting Started with Oracle Policy Modeling

Working with new starters to the wonderful world of Oracle Policy Modeling, I often come across interviews that have lots of Boolean attributes. Of course, deciding whether you need a Boolean or something else instead is part of the challenge for new learners : lots of “simple” ideas using Booleans turn into something more complicated and interesting later on.

The main challenges I want to focus on today are those related to the display of the Boolean attribute in the Interview : how to make it more appealing, useful and above all more efficient for the user. Let’s look at some interesting stuff :

Default Values in Oracle Policy Modeling

The simplest and often the most efficient approach is to ensure that the Boolean attributes have appropriate default values : both static and dynamic can be useful. The new input controls from the November 2016 version give us more flexibility (and less messing with CSS) to make things easier to use / view. Below for example is a Switch control, and a defaulted value.

Remember however that these are default values for the interview control, not for the attribute. As some of my colleagues this week found out, this can lead to a bit of a mix-up in trying to create dynamic display of values. Let’s investigate.

Oracle Policy Modeling - Switch Boolean and DefaultGetting Mixed Up with Boolean display

In the image above you can see the checkbox has been checked. This is because we added a default value to the control.

Oracle Policy Modeling - Setting Default

Earlier in this article I mentioned that the default value was (as you can see above) for the input control, not for the attribute. You can see this has a side-effect : when you try and set a second Boolean attribute to use the first one as a Dynamic Default, the perhaps expected behavior is not present. The second Boolean attribute does not register the value.

For example, in the following case, the image “200 Euros” is actually a Boolean Image Control. The colleague in question had changed the type of the Boolean input control to Image. The “clicked” and “unclicked” images had been added to the input as follows:

Oracle Policy Modeling - Images

The default value for the input control had been set as follows:

The Dynamic Default is based on a Boolean attribute which is true, if the customer has spent a value greater than 200 Euros. But the image will not be shown as checked, since the attribute underlying the image does not have a default value – the default value is on the input control. So the effect does not work. The attribute that should have made it work, does not have the value needed:

Oracle Policy Modeling - Boolean Not Dynamic

I have been seeing this quite a lot recently, perhaps because people have been experimenting with the Image control and the new exciting configuration options in November 2016 release. But the approach is not going to work, and the better, simpler (and working) approach is as follows:

  1. Add three images to your Screen. One blank, One for the “TRUE” and One for the “FALSE”. You might want  a third one to use in cases of uncertainty to ensure that the layout of the page does not shift too much when the “true” or “false” images are displayed.
  2. Set the display logic to use the value of the Boolean so that the blank is displayed when the value is uncertain, the “TRUE” image is displayed when the attribute is true and so on.

The Interview Screen looks something like this during the preparation. The first three bullets are three images. The final is an example of setting the display behavior.

Oracle Policy Modeling - Final Boolean Image Display

Now the overall effect is what you would expect : changing the value of the threshold (here, 201) to a value where the Boolean is true, triggers the display of the image in Oracle Policy Modeling debug.


I hope this clears up some things for some of my colleagues this week.

OPA 12 – November 2016 Release New Feature Review #2

OPA 12 – November 2016 Release New Feature Review #2

Part One is here.

Continuing our review of new features in the latest version of the Oracle Policy Automation family, OPA 12 – November 2016 Release; some of the most interesting new features concern the user interface as we were discussing last time round. There are a couple of things I want to applaud loudly (having often spent time making them happen in earlier versions).

  • The ability to create image groups. We have all seen them on modern websites. Instead of a row of radio buttons or a list, we have icons. The icons have two states : clicked or unclicked. The user “gets the idea” in about 2 seconds flat:

These now can be created purely from the Oracle Policy Modeler interface. No more need for image sprites, CSS or anything else. I am disappointed though that the “hover” state is not supported.

  • Slider Controls. The ability to map a numeric attribute to a slider, complete with upper and lower bounds. That is cool and takes another mess of JavaScript off my shoulders.

OPA 12 – November 2016 Release

The slider and the image group are just two of the new graphical features. The third one I am going to talk about today also will make our lives (and those of our consumers) much more fun. The capability to have dynamic update of an attribute, live, on the same screen as the source attributes, is very nice indeed.

I don’t think it will make a huge difference in a lot of cases, but if you can do it, and you don’t need to have rafts of JavaScript any more, I’m in!

OPA 12 – November 2016 Release

In the example above, changing the values in the area (1) changes the value in (2) with no change of page. JavaScript and jQuery we love you!

Next time we will look at some great new features in the back end of OPA 12 – November 2016 Release! Until then, have a great day!

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…


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.


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.