Tag: Debug

JSON Extension File

JSON Extension File

As many, but not all readers are probably aware, the Oracle Policy Automation JavaScript API is restricted in terms of what data it can manipulate in code. The default position is simple. If you plan on working with (accessing, updating or whatever is appropriate given the nature of the data and the type of attribute or entity instance) information from the Data tab of Oracle Policy Modeling then it must be present on the Screen that contains your Extension.

Here is a simple example to illustrate. Suppose you have a project that infers a list of Metro Stations. These stations are inferred in some way by Excel or Word rules. You wish to use a drop-down to allow the user to select one of those stations.

You decide to use the much-downloaded educational example called  Dynamic Options from Instances which you found in the OPA Hub Shop. So far so good. You look at the example Project and you see this:

JSON Extension File - Before

Cool. It’s a demonstration of a dynamic options list (at the bottom) driven by the entity instances (at the top). And the console shows some cool output to highlight the construction of the list. On the left, you can see that the interview is made up of two Screens. Excellent. Then you decide to split the interview into three Screens – separating the Instances from the Selection. Sounds really cool and a better layout. Now you see this in the Debugger:

JSON Extension FileWhich I think you will agree, is sub-optimal. Our extension just fails miserably. But now, it’s opm.extension.data.json to the rescue. We create this file in the resources folder and populate it according to our needs. In this case, we add – and this is required for any entity attributes – the relationship name (the technical name, not the textual name) and then we declare any attributes we want. So our file looks like this:

JSON Extension File Example

We re-debug and everything is back to normal. Re-cool. Obviously we should avoid putting too many elements in there – especially parent – child relationships which can result in masses of JSON being generated by Oracle Policy Automation and made available to your JavaScript, potentially creating performance bottlenecks. But for our little example, it’s perfect.

Input REST Batch Requests into Debugger

Input REST Batch Requests into Debugger

One of the new features introduced in 19C is the ability to use REST batch sessions (or requests, to give them their real name) directly in the Debugger. This is a great leap forward. Up to now, where I am working at the moment, we had built a tool to translate the REST into XML but it was still less than optimal.

So you can imagine how excited I was when I saw this new feature arrive in the product. There is, however, one major issue that I still find very frustrating. You will understand perhaps if I show you an example. Let’s consider the following. I have a batch of 10000 REST Batch cases that have been used in our testing and saved in JSON format. Now I want to open one of these in my Debugger to investigate what is happening. I open the project in Oracle Policy Modeling and I rush to the Debugger.

REST Batch

The pop-up window shows that my JSON file has been loaded, and shows me…the case id. Which from a functional point of view, of course, tells me nothing at all. Most of the testers here would be unable to remember which case represents which testing scenario. What we would have loved (and we are going to ask for) is the possibility to choose what to display in that window. For example, in our case, maybe if we show the identifying attribute from one of the entities being used, that would be more than enough for us to be able to recognize which case it is.

This might not seem a big deal but when you have an operations department who simply sends you the file and says it does not work i(they don’t necessarily know anything about Oracle Policy Automation apart from how to run it) it can be frustrating working backwards from REST case numbers back to scenarios that we can relate to our Test Cases in Excel.

I’m going to be accused of mixing everything up but it would be nice to have something easier to recognize, or perhaps a parameter that we could change.

Chrome Debugging Policy Modeler Interviews

Chrome for Debugging Policy Modeler Interviews

When looking into an Oracle Policy Modeler Debug session, I often want to view the Interview in Google Chrome, even at an early stage. The embedded Web Browser of the Debugger being Internet Explorer-based (and for various reasons which I quite understand, not having all the Context Menu options that normal IE has), I want a quick way to get into Chrome. I need to see the CSS, the JavaScript, and all the rest. Basically give me a Browser Debug Console.

To do this requires Registry Editor work, but the result is worth the effort. Firstly, let me again make clear I am not responsible for anything you choose to do with this information – you should think before doing anything in the Registry, and make backups. The example I am giving is for Windows 10, since it seems to be the least obvious solution – certainly it took a fair bit of searching on the Internet to get this working.

Add the following Key to add the ability to call Chrome directly from a URL in Internet Explorer, so to speak. You are going to create a new protocol to add to the http:// https:// file:// res:// and so on that you can use already for links. My protocol is called Trickshot://. Doing this in Windows 10 is much harder than in previous versions since there are many more restrictions in the domain of programs, defaults and so on.

In addition, just so we understand each other, we are basically using a security issue that could, in theory, be hijacked for nefarious purposes.

Several registry keys are needed. One in the HKEY_LOCAL_MACHINE and one in HKEY_CLASSES_ROOT branch.

[HKEY_LOCAL_MACHINE\SOFTWARE\Classes\Trickshot\shell\open\command]
 @="\"C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe\" -- %1"

[HKEY_CLASSES_ROOT\Trickshot]
@="URL:trickshot"
"URL Protocol"=""

[HKEY_CLASSES_ROOT\Trickshot\shell]

[HKEY_CLASSES_ROOT\Trickshot\shell\open]

[HKEY_CLASSES_ROOT\Trickshot\shell\open\command]
@="\"C:\\Program Files (x86)\\Google\\Chrome\\Application\\chrome.exe\" -- %1"

Obviously you would adjust the path to correspond to your system. Now if you go to Windows Run command and type “Trickshot:// google.fr” – with a space after the slashes and without the quotes, you should see Chrome open the relevant site. So now we could use this as a link in our Debugger. The link will work, but as a side effect, a window of the OPA Debugger will open, will fail to load the page (with an Unknown Protocol error) but then Chrome will start and you are looking at the Interview. You can start a new session, switch on the JavaScript Debugger of Chrome and so on.

Embed a label in your Interview (or put it somewhere, hard coded) that looks like this:

<a target="_blank" href="./" onclick="window.open('Trickshot:// ' + this.href, 'mynewwin');return false;">Go to Chrome</a>

This is just an example of course. Run the Interview with the Debug button as normal. Click your Go to Chrome link. When you click it, the Embedded Internet Explorer will fail to open it, but the registered application will take over and Chrome will load the page for you.

So the flow is something like this:

And of course, it is true, you could right click the normal Oracle Policy Modeler Debugger window, click Create Shortcut, minimize Oracle Policy Modeler, find the right Shortcut, run it in Chrome, ad eternam (so many useless icons on your Desktop!) and work like that. But I think this method is much faster and easier in the long run.

Have fun!

 

Worldwide
Logo by Southpaw Projects LLC