Welcome to the OPA Hub!


Tag Archives: Tutorial

JavaScript Extensions for Oracle Policy Modeling

JavaScript Extensions for Oracle Policy Modeling

It’s almost ready. The perfect Christmas gift (yeah, right, in bizarro-world) or New Year workout kit. The new book is due out in a few weeks, and you have the chance to win a free copy ahead of everyone else by entering our prize Survey (30 seconds) right now.

The book comes with 50 examples. You get them as Zip Files as well when you buy the book. The book covers all the different types of JavaScript Extensions that are currently available, with examples of each of them (sometimes many different examples) using easily-understandable business scenarios as the starting point, and using example projects from Oracle Policy Modeling – so you don’t need to install a Hub, or do anything special – which let’s you get started straight away.

  • Label Extensions
  • Input Extensions
  • Search Extensions
  • Options Extensions
  • Entity Collect Extensions
  • Entity Container Extensions
  • Button Extensions
  • Event Extensions
  • Navigation, Header and Footer Extensions

The OPA Hub Website Community has also stepped up and I am delighted to say that 8 examples (with credits) came from readers of this website. I am very grateful to them and encourage all of you to submit your ideas and code snippets for the next version.

Hopefully this book will appeal to non-technical people too – I wrote it in the same style as the others (Getting Started with OPA, Getting Started with OSvC) and tried to make it as accessible as possible to everyone.

Here, in avant-premiere, is the cover. And no, I’m not sure what those things are either. But they sure look exotic and tasty. I wanted a parsnip on the cover but these were available and they look good. These are important questions that you worry about late at night. The publisher’s website has been updated, watch this space for the launch date!

 

JavaScript Extensions

Table Headers Tabular Layout Trick 7

Table Headers : Tabular Layout Trick

Table Headers : Tabular Layout Trick

There is always much discussion when users first discover the Interview tab. Let’s be honest – not all of the comments are exactly positive. It all feels a bit, well, basic.

There are a number of things that catch you out at first (and indeed, later). So let’s take a moment to study tabular layouts and a common issue.

For this example I’m going to use the same project (Credit and Visa Cards) as the previous post, since that gives us two entities to work with.

Tabular Layout

Let’s consider that you want to display both entities using tabular layout. You create a Screen and set them both to tabular display. But let’s assume that you want to display the Visa Card with a couple of specifics. You want to include the provider of the credit card. So let’s set that up as a Value List and use an attribute on the Credit Card, and infer it on the Visa Card:

Table Headers Tabular Layout Trick 1So, with that now done, we want to display the Visa Card provider in the Entity Collect (as it is an inferred entity, we cannot use an Entity Collect). But we want to display it as a label as you can see in this screenshot (we added a name to the attribute as you saw in step one so we can reference it in our Screen:

Table Headers Tabular Layout Trick 2Notice how we added a label and used that to display the text of the provider? Using a label ensures three things

  1. It is read-only
  2. If the user is tabbing from input to input, the cursor will not get stuck in that field
  3. It doesn’t look like a read-only input, just a label (which is what we want).

But the downside is that the label does not have a table header in that column, since the Interview designer only adds those for Inputs:

Table Headers Tabular Layout Trick 4

I find it a shame that we cannot put table headers in this “tabular” column, since in HTML a table should have column headers. In fact if we take a moment to inspect this table in the browser, we note that annoying, there is a table header in the table:

Table Headers Tabular Layout Trick 5

So, we need to get that table header populated with our chosen text. But how shall we do it? We don’t want to create an Entity Container extension, since that would mean we have to do the whole thing from top to bottom. So we only want a little tiny change. We have a couple of choices.

  1. Create a Style Extension for the Entity Collect
  2. Create a Label Extension for stealth modification

Let’s try the first option, since it reveals some interesting facts about Styling Extensions. Firstly, get ready by doing the following; change the text associated with your entity in the Interview by double-clicking where the rectangle is, and entering whatever text you would like to display in the missing header.

Then add a compound Styling Extension to your Project. Tabular Containers allow for nested styling, like this:

OraclePolicyAutomation.AddExtension({
style: {
tabularContainer: function (control) {
if (control.getProperty("name") === "xContainer") {
style: {
headerRow:
YOUR STUFF GOES HERE
 
}
}
}
 
}
});

Notice the “headerRow” is a child of “tabularContainer”. And notice the line that says YOUR STUFF GOES HERE. Now for an interesting fact about Styling Extensions. They behave, to a reasonable degree, just like Control Extensions. They are really one and the same thing – the main difference of course is the handlers that are exposed in Control and Interview Extensions.

Drop jQuery into your resources folder, and then replace YOUR STUFF GOES HERE with the following line:

$("#opaCtl4th0").text(control.getCaption());

Of course, the jQuery selector may be different for you but it is easy to find the “header” I illustrated in the previous screenshots. Open your Project in a real Browser (Ctrl+F5) for debugging and take a look at the results:

Final Header Result

Our Styling Extension has added the text to the header, drawing it from the Interview Screen Entity Container definition, and we have it where we want it. Of course, you could style it as well.

But it goes to show that Styling Extensions are really not very different to Control Extensions!

Fun with Aliases and Strings #3

Fun with Aliases and Strings #3

In the previous parts of this article (1, 2) we’ve taken the time to look at an amusing string-based manipulation technique which has helped us create a long string from lots of strings. Of course, the main reason for the example was to showcase two of Oracle Policy Automation’s language features, namely logical loops and aliases.

In this final part we will look at some of the downsides and potential challenges relating to strings and logical loops, and a few other things besides.

  1. Inferring instances of an entity to impress your friends

This can go wrong of course. In the current example you must enter the instances manually either in the Debugger or in the Interview itself. But what if you decided to infer them, for example from an Excel spreadsheet. Regular readers will know that we’ve hacked and worked with Excel many times in the past, and it comes as no surprise to us that on a single instance of Oracle Policy Automation, with the instances inferred from an Excel spreadsheet, the following will occur regularly as soon as you get into the 150,200 instance range:

Aliases and Strings Error

Closely followed (of course) by the following in the Interview:

Aliases and Strings HTTP Error

Obviously there are lots of configuration changes we can make on WebLogic (if you have access to it) to ensure we are running the JVM with appropriate memory, in Production mode and so on. But hopefully the point is clear. Inferring instances (large volumes) can be costly in terms of performance / memory.

2) Entering lots of instances manually to impress your friends.

It is worthwhile remembering that logic loops have a 1000 iteration limit – if they cannot be stabilized by then, an error occurs. So assuming you add 1001 instances of the ticker tape manually using the Interview or the Debug, you would expect to hit the logical loop ceiling. Oracle Policy Automation gets out of the loop, just in case it goes on for ever and ever. The easiest way to test this is to use the Test Case format and try out your logical loop with zero to many iterations in order to verify that you are never going to have the scenario where there are more iterations than the limit.

999 InstancesAliases and Strings 999 Cases
1001 Instances
Aliases and Strings 1001 Cases

For the same reason, the warning about logical loops on the Rules Tab : if you do decide to hide it, will you remember it in 6 months time? Have you documented your tests somewhere?

Have fun!

Calendar Black Out Dates with Control Extensions

Calendar Black Out Dates with Control Extensions

The OPA Hub Website is always happy to hear from readers and learn about the things they are doing and trying to do. In this case, this article was inspired by our reader AF, from Adelaide. The question was; how can we implement a calendar control, to allow the users to select a date – but the calendar control must be able to black-out certain dates (public holidays, non-work days). It’s the sort of thing we probably can all relate to.

The Calendar control that Oracle Policy Automation uses is a very standard JavaScript dropdown, but there is little in the way of configuration in respect of the dates shown. We can style the calendar and we can offer two different ways to enter dates (either as the traditional calendar or the three-fields-in-a-row style that some applications use).

So it comes down to what can be done with an Extension. Regular reader will remember that we have spoken about calendar controls before, on the subject of Year-Only Selection. So that Extension will be the basis of this article.

Firstly, what are the tools we might need?

  • jQuery
  • JQuery UI, especially datepicker

The datepicker widget from jQuery supports a variety of user-related events, including one called BeforeShowDay, which is where we can come in a specify which days should not be clickable. They remain in the calendar display of course.

The basic concept therefore, for this demonstration is:

  1. The user can select a date from the control. Certain days are not available.
  2. The control must handle both adding a date when the date is not currently entered, as well as when the date is already entered and the user wants to correct it (for example, going back to a previous screen in the interview.
  3. The date must of course be saved to our chosen attribute.

As always this is without any warranty or guarantee of fitness for purpose. It’s a quick demonstration that you can then add to and correct yourselves.

 

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
88
89
90
91
92
93
94
95
/**
 * Richard Napier The OPA Hub Website March 2019
 * Educational Example of Custom Date Control Extension
 * I will remember this is for demonstration purposes only
 */
OraclePolicyAutomation.AddExtension({
	customInput: function (control, interview) {
		if (control.getProperty("name") == "xDate") {
			return {
				mount: function (el) {
 
					var myDatePicker = document.createElement('input');
					myDatePicker.setAttribute("id", "dateselect");
					var mySessionDate = interview.getValue("dt_session");
 
 
					el.appendChild(myDatePicker);
 
 
					$('#dateselect').datepicker({
						dateFormat: "yy-mm-dd",
						onSelect: function (dateText) {
							var RecoveredDate = dateText;
 
							interview.setInputValue("dt_circ", RecoveredDate);
 
						},
						beforeShowDay: function (date) {
							var array = ["2019-03-14", "2019-03-15", "2019-03-16"]
							var string = jQuery.datepicker.formatDate('yy-mm-dd', date);
 
							return [array.indexOf(string) == -1]
						}
					});
 
					var mySelectedDate = "";
 
					if (interview.getValue("dt_circ") == null) {
 
						$('#dateselect').datepicker("setDate", mySessionDate);
						var RecoveredDate = mySessionDate;
 
						interview.setInputValue("dt_circ", RecoveredDate);
 
 
					} else {
 
						var myPreviouslySelectedDate = new
							Date(interview.getValue("dt_circ"));
 
 
						var myPreviouslySelectedDateAsDate = new
							Date(myPreviouslySelectedDate);
 
						var myDayPrefix = "";
						var myMonthPrefix = "";
						if (myPreviouslySelectedDateAsDate.getDate() < 10) {
							myDayPrefix = "0"
						}
						if (myPreviouslySelectedDateAsDate.getMonth() < 10) {
							myMonthPrefix = "0"
						}
						var myConvertedYear = myPreviouslySelectedDateAsDate.getFullYear();
						var myConvertedMonth = myPreviouslySelectedDateAsDate.getMonth() + 1;
						var myConvertedDay = myPreviouslySelectedDateAsDate.getDate();
						var myPreviouslySelectedDateOnly =
							myConvertedYear + "-" + myMonthPrefix + (myConvertedMonth) + "-" + myDayPrefix + myConvertedDay;
 
 
						mySelectedDate = myPreviouslySelectedDateOnly;
 
 
						$('#dateselect').datepicker("setDate", mySelectedDate);
 
 
						var RecoveredDate = $('#dateselect').datepicker("getDate");
 
						interview.setInputValue("dt_circ", new Date(RecoveredDate));
					}
				},
				update: function (el) {},
				unmount: function (el) {
					var RecoveredDate = $('#dateselect').datepicker("getDate");
 
					interview.setInputValue("dt_circ", new Date(RecoveredDate));
 
					var myPicker = $('#dateselect');
					myPicker.remove();
 
 
				}
			}
		}
	}
});

Calendar Black Out Dates with Control Extensions – About the Code

The first part of the Mount is basically setting up the jQuery datepicker to be able to hide some days. We also set the date format to the international YYYY-MM-DD that we all know. Of course a more sophisticated approach would check the region and apply the correct format.

Line 22 Sets up the Select Event and Line 29 the BeforeShowDay  Event.

We attempt to grab the value of our user-entered date (dt_circ) and place it in the date control. If that is unknown or null, then we will default to the current date.

When the user selects a valid date, we will of course copy it into the attribute again.
Finally, when the Unmount fires, we will clean up.

The End Result

 

In a later post we will look at using an entity to store the blackout dates. Stay tuned! For the time being the Project is in the OPA Hub Shop.

What is Happening Here – Date Function with Wrong Date

What is Happening Here – Date Function with Wrong Date

See if you can guess : What is Happening Here?

Below is a project written in Oracle Policy Automation 12 (this was actually in 12.18B but it has no bearing on the example). It has only one attribute : the date of the next visit. This is written as follows:

The date of the next visit= YearEnd (AddYears(the current date;1))

The date you are running the Debugger, the current date is November 19, 2018. The rule should perform a simple assignment, taking the current date, adding a year and then using that as the input for the YearEnd function. So :

YearEnd(November 19, 2019)

This should give the value of December 31 2019. Also, there are no other attributes in this project. There are no JavaScript extensions, no custom controls, no CSS or other additions. The project is being built using English language. The project does not have any translations, forms, or anything else inside it. But the Debugger  session of the Oracle Policy Automation Interview displays the following:

OPA 12 - What is Happening Here

The date is incorrectly showing 12/31/20. So what is happening here? Even more fun, the Data tab of the Debugger shows the following:

OPA 12 - What is Happening Here

The value is correct on the right, wrong on the left. So what has happened to the Oracle Policy Automation project in this example?

You are free to give the answer, if you know it, in the comments. I will come back in a couple of days and explain. And before you ask, yes, I can across this in the real world yesterday and it is not a bug, it did not require a Service Request, and somebody had done something. The behavior is entirely reproducible I would imagine in any language.

Sometimes you want to write about something (in my case, I wanted to look at Silent and Hidden settings) but life gets in the way. This was such an amusing thing (with hindsight) that I decided to write about it instead.

Enjoy this and hopefully you will immediately have spotted the possible culprit. You can peruse the documentation online here.

Guest Post : Time Based Reasoning Worked Example

Guest Post : Time Based Reasoning Worked Example

It’s with great pleasure that I introduce you to Evert Fernandes, CTO at Magia Consulting UK Ltd. A self-confessed OPA geek, Evert has stepped up and written this article about Time Based Reasoning (and hopefully some more ) for the OPA Hub Website. Thank you Evert and…over to you!

Time Based Reasoning (TBR) – also known as Temporal Reasoning – is one of those subjects that new OPA developers tend to struggle with. It’s a more advanced subject that – once mastered – can provide huge benefits to your project.

In this article I will try to explain what TBR is, present a use case and provide a walk-through on turning the use case into rules.

So, what exactly is Time Based Reasoning?

Time Based Reasoning allows the rule developer to create rules that include attributes which contain values that are subject to change over time.

It is able to conclude rules like:

  • What’s the amount of daily benefit the citizen was entitled to on June 26th, 2017?

Time Based Reasoning Worked Example

Let’s have a look at the following use case:

“How much benefit is the citizen entitled to between 01-01-2017 and 31-12-2017 (inclusive)”

The following rules apply:

  • If the person is not married, the daily allowance is $10. If the person is married the allowance is $14
  • The person can only claim benefit if the daily income is less than $200.

For the sake of simplicity, we will only look at a binary relationship status, married and single. The real world is more nuanced and complicated, but feel free to expand on this example. 😉

As you can see, the mix of variables already creates quite a complex and fluid situation, especially considering that any of the variables are subject to change over the period in question (01/01/2017 – 31-12-2017).

So, let’s start by looking at the first element and create some rules:

OPA 12 - Time Based Reasoning Worked Example 1

There are a number of things happening in these rules, let’s take a closer look.

First of all, a rule table has been created (ALT + Z) to determine the daily allowance amount based on marriage status, $14 when married and $10 when single. The single status is implied by the ‘otherwise’ conclusion, i.e. the person is single because the person is not married.

The second rule calculates the total allowance over the time period, starting on January 1st 2017 and ending on January 1st 2018. The reason the end date is January 1st 2018 and not December 31st 2017 is because the end date is not included, so we simply add a day.

The function is called IntervalDailySum and takes in three parameters:

  • The start date (inclusive) of the period over which the calculation needs to take place;
  • the end date (exclusive) of the period over which the calculation needs to take place;
  • the rule text of the attribute over which the total daily allowance over the period needs to be calculated.

In this example, we provide hard coded values for the start and end dates. In the real world, the start and end dates will most likely come from date attributes.

We now need to test the rules. In order to do this, we start the OPM debugger and head to the data tab:

OPA 12 - Time Based Reasoning Worked Example

As you can see, not a lot is happening here. Let’s give the citizen a marital status by setting the value of ‘The citizen is married’ to ‘True’.

OPA 12 - Time Based Reasoning Worked Example

So far, so good. We have a marital status and OPA is able to work out the total allowance (365 days x $14 = $5110).

Let’s now assume that the person was single at the start of 2017, got married on March 1st 2017 and was single again on September 1st 2017 (don’t worry, they’re still friends! 😉).

How do we enter that data? OPA provides a handy feature called ‘Change Points’ to handle this.

Let’s reset the value for the citizen marital status:

OPA 12 - Time Based Reasoning Worked Example

Click on ‘Change Points’:

OPA 12 - Time Based Reasoning Worked Example

What this allows us to do is to take the attribute and set different values for different slices of time.

You can use ‘Add’ to add a new change point. Once a new point is created, you can set the date and value at that point in time.

Let’s add two change points. One on March 1st 2017 with a value of True and the other on September 1st 2017 with a value of False. Use the Date picker below the change point list to pick the dates.

OPA 12 - Time Based Reasoning Worked Example

The eagle eyed among you may have spotted that I’ve set the value at the top to ‘False’.

What this is saying is:

  • Until March 1st 2017, the value is False.
  • Between March 1st 2017 (inclusive and August 31st 2017 (inclusive), the value is ‘True’.
  • From September 1st 2017 and after, the value is ‘False’.

So, click ‘OK’ and let’s inspect the effect of our handiwork in the debugger:

OPA 12 - Time Based Reasoning Worked Example

There’s a lot more information here and one of the first things you’ll notice is that the total allowance has changed from $5110 to $4386.

If we break down the individual periods, you will see why:

  • January 1st – February 28th = 59 days x $10 (Single rate) = $590.
  • March 1st – August 31st = 184 days x $14 (Married rate) = $2576.
  • September 1st – December 31st = 122 days x $10 = $1220.

$590 + $2576 + $1220 = $4386!

Have a play with different dates and change points and you will find OPA is very good at working this stuff out for you.

OPA also offers a way to visualize this data. Right click the ‘the daily allowance for the citizen’ attribute and select ‘Show in Temporal Visualization’:

OPA 12 - Time Based Reasoning Worked Example

A new tab will appear top left named ‘Temporal Visualization’. If you click it, you will see:

OPA 12 - Time Based Reasoning Worked Example

This visualization confirms that we start off with $10/day, changing to $14/day from March 1st and changing back to $10/day on September 1st.

Time to complicate things a little by adding another variable to the mix in the shape of the daily income.

Let’s assume that the citizen started 2017 with a daily income of $150. Then later in the year the income rose to $250 and later yet, the income dropped to $180.

In order to deal with this new variable, we will change the rule that calculates the daily allowance to include the daily income for the citizen:

OPA 12 - Time Based Reasoning Worked Example

Remember that OPA will evaluate top down, so first it will check to see if the person is married and whether the daily income is less than $200. If this is false, it will check to see if the income is less than $200 and finally, if the citizen is not married and the daily income is greater or equal to $200, the ‘otherwise’ clause will apply.

Make sure the updated rule validates by pressing the ‘Validate’ button.

Now let’s start a debug session and have a look at the outcomes.

Start your debug session and navigate to the ‘data’ tab.

Supply the exact same values as the first example, making sure to set up the change points correctly.

Fun fact: Chances are that OPA still has your previous values in memory, saving you the need to re-enter them!

Check to see that you’re still getting the correct values.

You should see something like this:

OPA 12 - Time Based Reasoning Worked Example

Let’s set the value and change points for the daily income:

OPA 12 - Time Based Reasoning Worked Example

Click ‘OK’ and inspect the values in the data screen:

OPA 12 - Time Based Reasoning Worked Example

As you can see, the total allowance has now been set to $1926 (down from $4386).

We can have a look at what’s been happening in the Temporal Visualization tab.

Make sure the following attributes are shown by going to the debug data tab and right-clicking and selecting ‘Show in Temporal Visualization‘:

  • the daily income for the citizen
  • the citizen is married
  • the daily allowance for the citizen

Go to the ‘Temporal Visualization’ tab. You should see something like this:

OPA 12 - Time Based Reasoning Worked ExampleOPA 12 - Time Based Reasoning Worked Example

As you can see, there’s quite a bit going on here and the daily allowance for the citizen will vary based on marital status and income.

What you will hopefully be able to see is that, when it comes to dealing with changing circumstances, things can get quite complicated quite quickly. In the example we only dealt with two variables but throw in more variables and working out the right amounts would become very complex! Utilizing the out-of-the-box OPA temporal reasoning functionality allows you to manage the complexity of dealing with changing circumstances over time.

More information on Temporal Reasoning can be found in the OPA documentation:

https://documentation.custhelp.com/euf/assets/devdocs/cloud18c/PolicyAutomation/en/Default.htm#Guides/Policy_Modeling_User_Guide/Temporal_reasoning/Temporal_reasoning.htm

or in the Function Reference:

https://documentation.custhelp.com/euf/assets/devdocs/cloud18c/PolicyAutomation/en/Default.htm#Guides/Policy_Modeling_User_Guide/Work_with_rules/Function_references/FunctionReference.en-US.html

Finally for those who were wondering, the daily amount that the user is entitled to on June 26th is…

OPA 12 - Temporal Reasoning Worked Example

OPA 12 - Temporal Reasoning Worked Examplewhich is $14!

Thanks to Evert for his time and excellent article abut Time Based Reasoning. Readers who what to look at more Time Based Reasoning articles can search here.

Until the next time. If you want to write for the OPA Hub Website, reach out via our Contact Page.

Temporal Reasoning #5 : Temporal Attributes in Interviews

Temporal Reasoning #5 : Temporal Attributes in Interviews

In the final part of this mini-series, the OPA Hub Website continues to look at Temporal Reasoning and in this particular chapter discusses the display of Temporal Attributes data in the Interview experience.

If you missed any of the previous parts of the series, they are here:

So now that the we have a bit of understanding of how these data elements work, what about displaying them in a good way to the end user in the Interview. Well, part of the answer is hidden in part four of this series. We cannot actually display temporal attributes for data entry in an Interview (so conversion comes in very handy).

Let’s be more specific. Using the project from the previous chapter, in 18C, when an attempt is made to display the temporal information on a Screen, various things happen that underline the some important concepts:

Temporal Attributes in Interviews Animation OPA 12Please excuse the retro-style animated GIF above. But the demonstration above illustrates the fact that Temporal attributes and their change-points are complex data types that cannot be handled in a “normal” way. The one exception to the above is if you have a Temporal attribute whose values are the Goal of the interview, then an Explanation will display the data in a coherent way:

OPA 12 - Viewing Temporal Attributes in Interviews

If your project is using RuleScript and your data is pre-seeded, then potentially you could access it by deriving a string value which is a concatenation of the different values and displaying that attribute using a label control.

// RuleScript(myString) <- (temporalBankBalance)
function FindHighest(global) {
	console.log("Starting RuleScript");
	var v = global.temporalBankBalance;
 
		console.log("Base Value of v " + v._baseValue);
		var idx,
		maxVal = null;
		var myString = "";
		console.log("Length of Temporal Array " + v._changeValues.length);
 
	if (v._changeValues.length <= 0) {
		global.myString = "No Temporal Values";
	} else {
		console.log("Getting Temporal Values");
		for (idx = 0; idx < v._changeValues.length; idx++) { var changeValue = v._changeValues.valueAt(idx); if (changeValue != null && (maxVal == null || changeValue > maxVal))
				maxVal = changeValue;
		}
		global.myString = global.myString + changeValue + ";";
	}
 
}

But given that RuleScript is experimental, that it’s use cases are highly controlled this would be a very bad idea. Plus it would only work if the temporal values were pre-seeded into the Interview, which renders it all very complex.

So what is plan B? It might be to use something like the Entity Container Extension that we have previously looked at (which would imply using the conversion technique mentioned in part four).

If you are looking for a quick and dirty way to get at the Temporal values, even though the JavaScript Extensions do not actually support them today, the values are still accessible. They can be accessed using something like this. I have not published this as a download since the snippet below is very primitive.

 

/**
 * Richard Napier The OPA Hub Website August 2018
 * Educational Example of Custom Container with a Timeline inside
 * I will remember this is for demonstration and educational purposes only
 */
OraclePolicyAutomation.AddExtension({
	customLabel: function (control, interview) {
		if (control.getProperty("name") === "xTimeline") {
 
			return {
				mount: function (el) {
					var script_tag_addition = document.createElement('script');
					script_tag_addition.setAttribute('src', '${resources-root}/js/timeline.min.js');
					script_tag_addition.setAttribute('type', 'text/javascript');
					document.getElementsByTagName('head')[0].appendChild(script_tag_addition);
					var stylesheet_tag_addition = document.createElement('link');
					stylesheet_tag_addition.setAttribute('href', '${resources-root}/css/timeline.min.css');
					stylesheet_tag_addition.setAttribute('rel', 'stylesheet');
					stylesheet_tag_addition.setAttribute('type', 'text/css');
					document.getElementsByTagName('head')[0].appendChild(stylesheet_tag_addition);
 
					var myDiv = document.createElement("div");
					myDiv.setAttribute("class", "timeline");
										myDiv.setAttribute("data-mode", "horizontal");
					el.appendChild(myDiv);
 
 
					var myDivWrap = document.createElement("div");
					myDivWrap.setAttribute("class", "timeline__wrap");
					$(".timeline").append(myDivWrap);
 
					var myDivChild = document.createElement("div");
					myDivChild.setAttribute("class", "timeline__items");
					$(".timeline__wrap").append(myDivChild);
 
					// Don't do this, it relies upon the temporal attribute
					// being the only one in Global exposed on the page as a %label%
					var myTemporal = []
					myTemporal = control._source.screen.config.data[0].instances[0].attributes[0].value.changePoints
						for (var i in myTemporal) {
							var iterateDIV = document.createElement("div");
							iterateDIV.setAttribute("class", "timeline__item");
							iterateDIV.setAttribute("id", i);
							$(".timeline__items").append(iterateDIV)
							var iterateDIVContent = document.createElement("div");
							iterateDIVContent.setAttribute("class", "timeline__content");
							$('.timeline__item[id="' + i + '"]').append( "GBP "  + myTemporal[i].value + " on " + myTemporal[i].date)
						}
				},
				update: function (el) {},
				unmount: function (el) {
					var myDiv = $(".timeline");
					myDiv.remove();
 
				}
 
			}
		}
	}
});

The above snippet relies upon a jQuery plugin to display the data. This gives something like this, a visual timeline on the left of this page:

Temporal Attributes in Interviews JavaScript Extension

Of course there are hundreds of Timeline plugins, each more sophisticated than the other, on the Internet.

We hope that this series has brought to light some of the key features of temporal reasoning, and thanks to Orlando who suggested this series in the first place. Have a good day and see you soon!

 

Detail Pop-up in Oracle Policy Automation

Detail Pop-up in Oracle Policy Automation

The other day someone came to me with a curious and interesting problem. They had a number of entity instances, inferred in an Excel spreadsheet. These had to be displayed in the usual way with an Entity Container in a Screen of Oracle Policy Modeller. So far so good, I hear you say.

Detail Pop-up in Oracle Policy Automation 1

The inferred attributes (which in the end would probably be coming from a data source, but for now come from Excel as inferred instances) included a Text attribute that was frankly far too large to display correctly in the Screen, given that there might be a few rows of instances in the final result.

We experimented with lots of different layouts, dynamically hiding and showing items based on various criteria in order to make room, but in the end we came to the conclusion that we needed some sort of Detail Pop-up in Oracle Policy Automation – something that could be called upon by the user as and when they needed it, but ignored (and invisible) when not needed.

Here is the starting point for our adventure.

The Screen above is populated with all the instances of the student’s scholarship. On the left is a set of information that we need to display on request. Normally we will only display the name of the Scholarship. You will see in the list of attributes there is an overview ( a text attribute), a deduction ( a currency attribute) and a renewable status (a boolean attribute). There are a few others, including the contact details (a text attribute, which is a URL).

So we are going to customise the label control I have just described. It is “inside” the Entity instance loop : so in reality there will be one per instance. We need our label to contain, as you would expect, the correct information. We wish to avoid pop-ups (nasty!) and dialogs (too complex for a simple window) and tool-tips are too small and simple for the data we have. The label shown will have a custom property called “name” and will be used as a hook for our JavaScript Extension.

We experimented with all sort of things before we went for this option : JavaScript is a last resort. We were frustrated by the behaviour of hidden items that appeared slowly (we could see “uncertain” appearing before the out of the box JavaScript populated the bound controls). So it was going to be JavaScript.

So,  our Detail Pop-up in Oracle Policy Automation needs to meet these challenges. We are going, as a simple demonstration, to use a CSS toggle to show or hide the relevant data for our instances. We can set the scene as follows:

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
.area {
position:relative;
color:#0645AD;
font-weight:400;
}
 
.area:hover {
text-decoration:underline;
text-decoration-color:blue;
cursor: pointer;
}
 
.fixed {
position:absolute;
top:190px;
left:465px;
border:0;
z-index:9999;
background-color:#FFF;
display:none;
height:300px;
width:420px;
float:right;
text-decoration:none;
text-decoration-color:#000;
text-color:#000;
padding:5px;
}

The above CSS file sets up two main classes and a pseudo-class for a mouse hovering over our row. The area is the area we will normally show – with just the name – and the fixed area is a fixed DIV which will display (or not) when we decide we want to visualise the information. Now for the main content of our customLabel extension. Here is the mount key with as usual, my simplistic attempts at coding : for the umpteenth time I’m not a professional – but my job is to show something can be done, and let other’s get on with making it happen.

 

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
{
 
if (control.getProperty("name") == "xLabel") {
return {
mount: function (el) {
var maindiv = document.createElement("div");
maindiv.style.visibility = 'visible';
maindiv.innerHTML = interview.getValue("scholarship_award", "scholarship", control.instance);
maindiv.classList.add("area");
maindiv.setAttribute("id", interview.getValue("scholarship_award", "scholarship", control.instance));
el.appendChild(maindiv);
 
var tooltipdiv = document.createElement("div");
tooltipdiv.style.visibility = 'visible';
tooltipdiv.classList.add("fixed");
tooltipdiv.innerHTML = control.getCaption();
tooltipdiv.setAttribute("id", interview.getValue("scholarship_award", "scholarship", control.instance));
el.appendChild(tooltipdiv);
 
$("div [id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").click(function () {
$(".fixed").hide();
$(".fixed[id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").html("<h6>Name : " + interview.getValue("scholarship_award", "scholarship", control.instance) + "</h6>");
$(".fixed[id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").append("<h6>Overview : " + interview.getValue("scholarship_overview", "scholarship", control.instance) + "</h6>");
$(".fixed[id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").append("<h6><b>Renewable</b>: " + interview.getValue("scholarship_renewable", "scholarship", control.instance) + "</h6>");
$(".fixed[id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").append("<h6><b>Maximum Value</b>: " + interview.getValue("scholarship_deduction", "scholarship", control.instance) + "</h6>");
$(".fixed[id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").append("<h6><b>Eligibility</b>: " + interview.getValue("scholarship_eligibility", "scholarship", control.instance) + "</h6>");
$(".fixed[id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").append("<h6><b>Minimum Grade</b>: " + interview.getValue("scholarship_min_grade", "scholarship", control.instance) + "</h6>");
$(".fixed[id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").append("<h6><b>Contact</b>: <a href='" + interview.getValue("scholarship_contact", "scholarship", control.instance) + "' target='_blank'>SFAS Office</a></h6>");
$(".fixed[id='" + interview.getValue("scholarship_award", "scholarship", control.instance) + "']").toggle();
});
 
}

Here is the review of the Detail Pop-up in Oracle Policy Automation code shown above, starting with the usual check to make sure we are only working with our label and not any other label on the Screen. In lines 6 to 11 we add a new DIV (to replace the one that contained all those %substitution%s , and we populate it with only one attribute. Since that attribute is also unique, we use it as a handy way to populate the HTML id attribute.

In lines 13 to 18 we create a second, hidden DIV that uses the fixed class shown above.

In lines 20 to 29 we set up the click event so that the user can click on the label and the hidden text will be revealed. The code preview (I notice) has eaten the ending part of the line, so use the PDF version instead. Notice the use of getValue, with the entity name and the instance, to ensure that we create a DIV with a unique name and unique content. The content will be toggled (hidden or shown) when you click on it.

Finally the unmount is very standard, cleaning up our various pieces by removing them.

1
2
3
4
if (control.getProperty("name") == "xLabel") {
$(".area").remove();
$(".fixed").remove();
}

The end result looks like this, before the click:

Detail Pop-up in Oracle Policy Automation 3And after the click:

Detail Pop-up in Oracle Policy Automation 4

Our Detail Pop-up in Oracle Policy Automation prototype gives the user the information they need when they need it. Of course it can be extended and transformed into something much less ugly, but this is a good start. You can find the PDF in the Shop, it’s free!

List of Values, Display Values and Translations in Oracle Policy Automation

List of Values, Display Values and Translations  in Oracle Policy Automation

A common List of Values question that comes up is the following:

“How are list of values handled in Oracle Policy Automation, when I have more than one language? What gets put into the database?”

Of course, by “database” I mean whatever platform you are using to save the response from Oracle Policy Automation  : Oracle Sales Cloud, Oracle Service Cloud, Oracle Siebel CRM, Salesforce or any other.  For the record, the exact behaviour of your Connector will depend on how it has been programmed,but if it is doing what it should be doing, then the following information will apply.

The question that comes up is actually, to be fair, usually more detailed : people want to know the behaviour of the list of values both when it is created as a Screen element (single-use) or as a Value List (multi-use) and when there is more than one language involved. Well, fear not because the video below will answer all of those questions I hope, in a friendly and easy to follow way.

Imagine you have a Project in Oracle Policy Automation that includes an attribute of type Text, with a drop-down list to display values for the user.

  • What if there are multiple languages?
  • What if you use Screen-based Values?
  • What if you add Display Values as well as Values?
  • What if you migrate to Project Value Lists?
  • What editing might you have to do in your Translation file(s)?
  • What gets into the database?

List of ValuesAll these points will be covered in the video. Hopefully there will be no surprises in the video itself,  but it will be useful to see it in action and get confirmation of what you think might happen. And as mentioned previously, a big thanks to our OPA Hub Website Sponsors Mantis Solutions, makers of the OPA DB Connector, whose assistance made this video way easier to create and much faster to implement. If you are interested in Mantis OPA DB Connector, please reach out here.

 

Until the next post, I hope you are (at least those of you in the Northern Hemisphere) all having a pleasant Summer.

Temporal Reasoning in Oracle Policy Automation #3 : Time Travel

Temporal Reasoning in Oracle Policy Automation #3 : Time Travel

Following on from the previous parts of this series (which looked at the basics of Temporal Reasoning and Temporal Functions), this third post continues our investigation of temporal calculations in general, this time with a focus on another series of functions and concepts, that are closely involved in using temporal data to calculate numeric or currency amounts.

In the previous chapter of this series, we saw how the functions such as WhenLast() give us the capability to investigate the temporal data at our disposal and find out what was happening on a given date, according to the information you have.

How much would I have saved if?

Taking the example from the previous post and turning it upside-down, we can use Oracle Policy Automation to find out how much money would could save if we had been good and put money in our bank account. There are two principles here :

  1. We need to know how much money we are willing to save
  2. We need to know how regularly we are willing to put it in the bank account.

In real life, you might say to me:

“Richard, if I saved $1 a day, every day, since the beginning of the year : – how much money would I have now?”

In Oracle Policy Automation we can ask the same sort of question.  And of course, get the answer. The key points here are the daily sum, and the date range. In a sense, you are creating your own change points daily in order to calculate the result.

Again, it probably will not surprise you to know that there are a whole raft of Temporal Reasoning functions that work in similar ways to this one.  Suppose you admit to me, that you cannot save money on the weekend, because you like to go out and spend it instead.

“Richard, if I saved $1 a day every week day since the beginning of the year:- how much money would I have now?”

Your familiarity with Oracle Policy Automation probably helps you guess that the function IntervalDailySumIf exists, so you decide to use it, as in the example below.

At first glance, this looks alright. But it really isn’t. The problem is a common one when imagining Temporal Reasoning. The Boolean attribute “you are not spending the money instead” is not going to be very useful, since it is not a temporal value. You get to set it once in the Debugger – not for every weekend:

So mixing a Boolean and our temporal calculation produces a not very useful result. But thankfully Oracle Policy Automation can help. It includes a function to let us know if a day is a weekday or not, based on a range of dates. It returns a set of values that illustrate the changes. It is another example of a temporal reasoning function.

In the above case, the day is a weekday returns a set of change points showing you the way:

 

In the next episode of this series, we will look at the display of Temporal data to the end user, in a way that is easily readable.

Have fun