Welcome to the OPA Hub!

Archives

What’s New in Oracle Policy Automation 18B #2 Relationship Control Extensions

What’s New in Oracle Policy Automation 18B #2

The main thrust of this post first came into my head when I was writing one of the recent Back to Basics posts about Relationships. And as if by magic, Oracle Policy Automation went ahead and improved the product with something I felt was lacking. I should ruminate more often, perhaps they have telepathic powers over there. So in this post, What’s New in Oracle Policy Automation 18B #2, we are going to look at the new feature of the Control Extensions : the ability to customise the Relationship experience.

What’s New in Oracle Policy Automation 18B #2

The relationship above is a good example. In the course of a prototype, I designed the car and the passenger entities for a car-sharing enterprise. A car can have many potential passengers. For each journey, however, your passenger can only be in one car at a time. And yes, I understand that I could build a many-to-many and intersection the car and passengers or infer the current passengers or what have you, but this is just an example.

What’s New in Oracle Policy Automation 18B #2

So in the above example, you can see that I am in the process of selecting the passengers for each car. Putting aside the discussion about how best to model the data, there is a challenge here. The checkbox (which is the only display offered) is fine, but due to the lack of dynamism (?) in the display, the choices remain static. I mean by that you are able to choose an incoherent selection, with the same passenger being in multiple cars.

Of course, when you do so, the engine (correctly) gives you an error and you must correct your data entry. But what if we did it another way?

The core of this is the fact that now, in Oracle Policy Automation 18B, you can use the following in your Extensions:

control.getControlType() – which now will return “OneToMany” or “ManyToMany” and so forth for relationship controls. So your code could adapt the User Experience based on the cardinality.

control.getOptions() – returns an array of the different choices for the user ( the passengers in my case above). So you can retrieve the list of choices.

To help manage this kind of extension, control.getValue() returns an array of the selected values for your relationship (the instances that have been selected). So you can examine the selected values.

Let’s look at this code. It is, as always provided for educational and entertainment purposes (indeed, many will find my stream of consciousness code amusing). It is also available on the OPA Hub Website Shop page as a free PDF download. So let’s see What’s New in Oracle Policy Automation 18B #2 : Relationship Controls with an example.

 

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
/*
(c) 2018 Richard Napier The OPA Hub Website May 2018
Educational Example of Relationship Input Controls
I will remember this is for demonstration and educational purposes only
 */
 
OraclePolicyAutomation.AddExtension({
	customInput: function (control, interview) {
		if (control.getProperty("name") == "xPassengerSelect") {
			return {
				mount: function (el) {
					//console.log("Control " + control.getProperty("name") + " is a " + control.getDataType() + ", originally a " + control.getControlType());
					var myValues = [];
					//Previous values
					myValues = control.getValue();
					var myOptions = control.getOptions();
					//console.log("Obtained list of instances for control " + control.id);
					var myDropDown = document.createElement('select');
					myDropDown.setAttribute('id', control.instance.toString());
					myDropDown.setAttribute('data-instance', control.instance.toString());
					myDropDown.setAttribute('data-entity', control.entity.toString());
					myDropDown.setAttribute('multiple', 'true');
					for (j = 0; j < myOptions.length; j++) {
						var myoption = new Option(myOptions[j].text, myOptions[j].value)
							myoption.setAttribute("data-instance", control.instance.toString());
						myoption.setAttribute("data-entity", control.entity.toString());
						myDropDown.options.add(myoption)
						//console.log("Added list option " + myOptions[j].text);
					}
					for (i = 0; i < myDropDown.length; i++) {
						currentOption = myDropDown[i];
 
						if (myValues.indexOf(currentOption.value) != -1) {
							$("select [data-instance='" + myDropDown.getAttribute('data-instance') + "']").filter("option[value='" + currentOption.value + "']").attr("selected", "selected");
						}
 
					}
					$(myDropDown).change(function () {
 
						//New Values Selected
 
						for (i = 0; i < myDropDown.length; i++) {
							currentOption = myDropDown[i];
 
							if (currentOption.selected == true) {
								myValues.push(currentOption.value);
 
								//Disable All Values Matching Selected in other instances
								$("select [data-instance!='" + myDropDown.getAttribute('data-instance') + "']").filter("option[value='" + currentOption.value + "']").attr("disabled", "true")
 
							} 
 
						}
					});
					var deselectbutton = document.createElement("button");
					deselectbutton.setAttribute("type", "button");
					deselectbutton.setAttribute('data-instance', control.instance.toString());
					var deselectbuttontext = document.createTextNode("Deselect All");
					deselectbutton.appendChild(deselectbuttontext);
 
					el.appendChild(myDropDown);
					$(myDropDown).after(deselectbutton);
 
					$(deselectbutton).click(
 
						function () {
						$("select [data-instance='" + this.getAttribute('data-instance') + "']").filter(":selected").prop("selected", false);
						control.setValue("");
							$("select [data-instance!='" + this.getAttribute('data-instance') + "']").attr("disabled", false);
					});
 
					for (i = 0; i < myDropDown.length; i++) {
						currentOption = myDropDown[i];
 
						if (myValues.indexOf(currentOption.value) != -1) {
							$("select [data-instance='" + myDropDown.getAttribute('data-instance') + "']").filter("option[value='" + currentOption.value + "']").attr("selected", "selected")
 
						}
 
					}
				},
				update: function (el) {},
				unmount: function (el) {}
			}
		}
	}
});

So what are we looking at. There are probably four key areas in this rough prototype.

Lines 18 to 27 build a multiple-select drop-down instead of the check-boxes. Using HTML 5 data attributes, each option and each drop-down (there will be  drop-downs, one for each of the car ) is tagged with the instance name and the entity name. This is useful if you intend to have a page with lots of entity-related things on it , and it was useful in the Entity Collect example from a few weeks ago as well.

Lines  29 to 33 look through the existing values of the Control (maybe the user has already been working on this page, and has now come back to it for further editing) and selects programatically all those values that were chosen previously. Otherwise when you click the Next button and then the Previous button, you will no longer “see” your selections even though they actually have been selected.

Lines 38 to 58 handle the Change event if the user selects other items in the multi-select, and ensures that the corresponding items are deactivated in the other drop-downs.

Lines 58 to 78 create the Deselect All button for each drop-down, which removes all the selected items both from the drop-down and from the underlying control values, and re-enables the values in the other drop-downs.

Once again, I state for the record that this was just a “stream of consciousness” which became a bare-bones prototype. There are lots of holes in the code, and lots of repetition because I just wrote it in a single shot. So you have been warned.

It does, however, demonstrate the new functionality, so our post title What’s New in Oracle Policy Automation 18B #2 is fulfilled. This is something you could not really do in previous versions.


Have fun!

What’s New in Oracle Policy Automation 18B #1

What’s New in Oracle Policy Automation 18B #1

The team that creates and updates Oracle Policy Automation have once again been very busy indeed, and the latest and greatest release can be downloaded from the usual Oracle Technology Network pages, and the link to the documentation follows the usual schema, just with the new 18B tag in it. So What’s New in Oracle Policy Automation 18B ?

In this first post in a short series, we are going to be looking at the new features of this release, and there certainly are some crackingly good ones. Let’s get started with the integration-related changes and what they mean for Oracle Policy Automation 18B:

  • A new Integration Cloud Service OPA assessment Adapter

What's New in Oracle Policy Automation 18B ICS

A massively important piece of the integration architecture for Oracle Policy Automation just got a whole lot better. An Oracle Policy Automation assessment can now be called as a step in your integration Workflow built on Oracle Integration Cloud Service. The Oracle Policy Automation assessment adapter has been available as a pre-release version but by the time you read this, or shortly afterwards, it should be available from the list of Adapters on the Oracle Integration Cloud Service site.

  • Embeddable JavaScript Models

An embedded JavaScript model is essentially a completely self-contained rulebase which can run, therefore, in a disconnected scenario. This will be a game-changer for Internet of Things devices, as well as situations where you need to have lightweight, client-side rule execution. This feature does not support Interviews, and is license-based.

  • Inline Customer Portal interview widget

Service Cloud customers can now take advantage of the new IFRAMEless integration capability that we enjoy with Siebel CRM already.

  • New REST API Batch Assessment Licensing Options

The Batch Assess REST API can now be called if you are licensed for Oracle RightNow Universal Policy Automation Tier 3 sessions, even if you are not also licensed for Oracle Policy Automation Enterprise Assessment API. For more information on the licensing and restrictions contact your Oracle representative.

  • Cookie-less interviews

A real boon for Safari users (but not only Safari) : Embedded Interviews no longer require a Browser cookie, which potentially could stop the Interview from functioning in certain environments. CORS still applies for resources shared across domains but basic embedding should now be possible whatever the browser security settings.

  • New Inline API Interview

The new API is OraclePolicyAutomationInterview and it uses the same methods as in previous versions (StartInterview, ResumeInterview, BatchStartOrResume). This new API version enforces all interview element styles. Styles won’t inherit from the parent stylesheet, and interview extensions can be used to modify interview appearance.  Awesome news for customers looking to render a a transparent experience to their users.

  • Relationship Control Customization

In the second part of our What’s New in Oracle Policy Automation 18B post series, we will look at the new Relationship Control extension capability which I was wishing for only a few weeks ago!

Custom Entity Collect Extension in Oracle Policy Automation #2

Custom Entity Collect Extension in Oracle Policy Automation

In this second part of the series, we continue to investigate building a Custom Entity Collect Extension in Oracle Policy Automation, and complete the basic example of a working collector. The code is once again focused on pointing out big ideas, traps, suggestions and the details are left to you, dear readers. Everything you see here is free and you can use it anywhere but it is for educational and entertainment purposes only. The PDF version of the code is available in the OPA Hub Shop for free.

Building the User Interface

The next big chunk of code is all about continuing the work begun previously, specifically building the User Interface by adding input boxes and other User Interface elements to the page. We switch according to data type, and as before we add a number of valuable extra HTML attributes to our elements.

 

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
//GET KEY INFORMATION
									var theinstancename = myrecords[i][j].instance.toString();
									var theentityname = myrecords[i][j].entity.toString();
									var theattributename = myrecords[i][j]._source.config.attributeId;
 
									var myname = myrecords[i][j].id.toString();
 
									attrInput.setAttribute('id', myId);
									attrInput.setAttribute('data-entityname', theentityname);
									attrInput.setAttribute('data-instancename', theinstancename);
									attrInput.setAttribute('data-attributename', theattributename);
									attrInput.setAttribute('data-rownumber', j.toString());
									attrInput.setAttribute('name', myname);
 
									// CONVERT ATTRIBUTES OBJECT TO ARRAY
									var myAttributeObject = myrecords[i][j]._source.screen.clientState[theentityname];
									myAttributeObject = myAttributeObject[theinstancename];
									var myAttributeArray = $.map(myAttributeObject, function (value, index) {
											return [value];
										});
 
									//DISPLAY THE CORRECT VALUE IN THE INPUT BOX
 
									switch (myattributedatatype) {
									case "boolean":
										var response;
										switch (myAttributeArray[j].toString()) {
 
										case "true":
											response = true;
											break;
										default:
											response = false;
										}
										attrInput.checked = response;
										rowdiv.appendChild(attrLabel);
										$(attrLabel).after(attrInput);
 
										break;
 
									case "number":
										attrInput.setAttribute('value', Number(myAttributeArray[j]));
										rowdiv.appendChild(attrLabel);
										$(attrLabel).after(attrInput);
										break;
 
									case "text":
										attrInput.setAttribute('value', myAttributeArray[j].toString());
										rowdiv.appendChild(attrLabel);
										$(attrLabel).after(attrInput);
										break;
									case "date":
										if ($(attrInput).attr("data-datepicker") === 'true') {
											$(attrInput).datepicker();
											$(attrInput).datepicker("option", "dateFormat", "yy-mm-dd");
											$(attrInput).val( myAttributeArray[j]);
											rowdiv.appendChild(attrLabel);
											$(attrLabel).after(attrInput);
 
 
 
										}
										break;
 
									}

Whoa, easy there! So what is all of that about? The different kinds of data (Boolean, text, numbers, dates) need to be handled slightly differently, to display correctly.

Error Display

What happens if the Interview cannot continue (note that this example Entity Collect only handles errors on navigate, the default for Oracle Policy Automation Interviews) because of an issue? The user needs to know what they have done wrong, so they can correct it. Thankfully the errors are available to us (if they exist).

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
//HANDLE DATA ENTRY ERRORS AND ERROR DISPLAY
var myerrorobject = myrecords[i][j]._source.screen.errors[theentityname]
if (myerrorobject) {
var myerrorinstance = myerrorobject[theinstancename];
if (myerrorinstance) {
var myerrorattribute = myerrorinstance[theattributename]
if (myerrorattribute) {
var errorrow = document.createElement("div");
errorrow.id = "rowcontainer" + i.toString();
errorrow.setAttribute('data-entityname', theentityname);
errorrow.setAttribute('data-instancename', theinstancename);
errorrow.setAttribute('data-attributename', theattributename);
$("#errordiv").append(errorrow);
 
$(errorrow).append("Attribute : " + myerrorattribute.attributeId.toString() + " - " + myerrorattribute.message);
$("input[data-entityname='" + theentityname + "'][data-instancename='" + theinstancename + "'][data-attributename='" + theattributename + "']").css("border", "3px solid red");
}
}
}

In this section we build a small DIV for the errors, and add any errors that exist as rows within it. At the same time, the relevant attribute is highlighted with a red border.

Updating the User Interface

When the user makes changes, we need to handle them and ensure they are passed on. The last part of the code for today concentrates on handling each of the data types, and making sure the data is correctly passed to Oracle Policy Automation. This is quite tricky, and can necessitate quite a bit of review of the Investigate JSON to try and understand what it does not like, as the error in the Browser will most likely be a generic 500 error.

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
var inputtype = $(attrInput).attr("type");
var datepicker = $(attrInput).attr("data-datepicker")
 
switch (inputtype) {
case "checkbox":
$(attrInput).change(function () {
interview.setInputValue(event.target.attributes["data-attributename"].value, this.checked, event.target.attributes["data-entityname"].value, event.target.attributes["data-instancename"].value);
 
interview.saveData();
event.stopImmediatePropagation();
 
});
break;
case "input":
 
if (datepicker === 'true') {
$(attrInput).change(function () {
var mydate = $(this).datepicker('getDate');
mydate = new Date(mydate);
var mydateinstance = $(this).attr("data-instancename");
var mydateattribute = $(this).attr("data-attributename");
var mydateentity = $(this).attr("data-entityname");
var myisodate = mydate.toString();
function formatDate(mydate) {
var d = new Date(mydate),
month = '' + (d.getMonth() + 1),
day = '' + d.getDate(),
year = d.getFullYear();
 
if (month.length < 2)
month = '0' + month;
if (day.length < 2)
day = '0' + day;
 
return [year, month, day].join('-');
}
interview.setInputValue(mydateattribute, formatDate(mydate), mydateentity, mydateinstance);
 
interview.saveData();
event.stopImmediatePropagation();
 
});
 
} else {
$(attrInput).change(function () {
interview.setInputValue(event.target.attributes["data-attributename"].value, event.target.value.toString(), event.target.attributes["data-entityname"].value, event.target.attributes["data-instancename"].value);
 
interview.saveData();
event.stopImmediatePropagation();
 
});
 
}
 
break;
case "number":
$(attrInput).change(function () {
interview.setInputValue(event.target.attributes["data-attributename"].value, Number(event.target.value), event.target.attributes["data-entityname"].value, event.target.attributes["data-instancename"].value);
 
interview.saveData();
event.stopImmediatePropagation();
 
});
break;
}
 
}

And so this pretty much leaves us with a row builder, and an error builder. But the final part of the code is very important, specifically the Delete Button to delete the row you don’t want any more.

Delete Rows

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
//ADD A DELETE ROW BUTTON  AFTER EACH ROW
								var deletebutton = document.createElement("button");
								deletebutton.setAttribute("type", "button");
								var deletebuttontext = document.createTextNode(control.getRemoveButtonText());
								deletebutton.appendChild(deletebuttontext);
								//SET UP THE CLICK EVENT OF THE DELETE BUTTON
								$(deletebutton).click(function () {
									var myliveinstances = control._source.instances.slice();
									// FIND THE ROW THAT CONTAINS THE DELETED INSTANCE
									var found = myliveinstances.indexOf(event.target.parentElement.getAttribute("data-instancename"));
									control.removeRow(found);
 
									drawrows();
								});
								rowdiv.appendChild(deletebutton);

Delete the Right Row

The delete row feature needs to find the row in the live set of instances (the _source.instances) using the HTML element that is the parent of the button. So if you click the Button, which is on the third row of the HTML User Interface, then using the instance name we can find the correct row and remove it. This is because the control.removeRow() uses the zero-indexed array in control._source.instances, not the user interface you are building. For example, if you have four instances on screen, then you delete one, the HTML will show that instance 1, instance 3 and instance 4 remain for example. But the Array members are now marked as rows 0,1 and 2.

The code closes out with the standard stuff :

 

1
2
3
4
5
6
7
8
9
10
11
12
13
14
update: function (el) {$("#errordiv").empty();	drawrows();},
				unmount: function (el) {
 
					if (control.getProperty("name") == "xEntity") {
 
						$("#entitycollector").remove();
					}
				}
			}
		}
	}
})
 
 

And so, what remains to be done? Well, of course, reorganize all that code written as a stream of consciousness!

But seriously, the obvious ones are

  • Ensure that when an instance is created, but the user has not yet entered any data, that the error checking is fired ( you can actually advance to the next page and come back to see the errors, because of the way the error object is handled only on the mount , not on the update.
  • Ensure that errors are removed from the page when they relate to an instance that was deleted by the user.
  • Ensure that the HTML building includes CSS class information to facilitate a new look
  • Build out date-time input and currency input and saving

But I’m sure you will find time for that. Have a nice day and enjoy building your own Custom Entity Collect Extension in Oracle Policy Automation!

We’ll leave you with a short video.

Custom Entity Collect Extension in Oracle Policy Automation #1

Custom Entity Collect Extension in Oracle Policy Automation

The idea behind this post, as is often the case, came from a conversation with a customer about something unrelated to the actual result. Suffice to say we were discussing data collection in Oracle Policy Automation and the idea of Custom Entity Collect Extension in Oracle Policy Automation came up, vaguely. The difficulty with demonstrating such an Extension is that every situation will be different, and every extension will have lots of styling to “make it look like something different”.

Perhaps the most important thing therefore is to demonstrate a Custom Entity Collect Extension in Oracle Policy Automation without any custom functionality and without any styling, so you can use it as the basis for your own discovery sessions. Of course, as always (and in particular in this case, as the example is necessarily longer than most), the code is totally for prototype and demonstration purposes only, and I will leave it to you to take the ideas and run with them.

Custom Entity Collect Extension in Oracle Policy Automation Result Final

Alright let’s get started. The Project looks like the following screenshot; namely a single entity called the accident and a variety of input attributes. There are no rules in this Project at the moment.

Custom Entity Collect Extension in Oracle Policy Automation Result 1

The screenshot shows a number of things we will need to think about:

  1. The code will try to be generic
  2. The code needs to read Screen items like the text here
  3. The code needs to offer deletion of instances as well
  4. The code needs to display Boolean data as well as text or numbers
  5. The code needs to display dates with a date picker

The Project also has, for completeness’ sake, an entity container on the final Screen to review the data to make sure that what the user has done has been saved correctly. Of course, you can also check the Data tab in the debugger.

The basic principle of the code is common to all the different examples seen around the Web, namely the Entity Collect has a custom Property whose name identifies it to the JavaScript extension code. I won’t include it here but you can find it in the PDF version at the end of this series.

NOTE : The Code Viewer on this website eats some characters, so be careful (especially less than and greater than symbols)

Getting Started : Make a Container

The first part of our mouncode will build the infrastructure for our container. Fittingly enough, it will be a DIV.

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
return {
				mount: function (el) {
 
					// ADD ROW BUTTON THE TOP OF THE ELEMENT
					var button = document.createElement("BUTTON");
					button.setAttribute("type", "button");
					var buttontext = document.createTextNode(control.getAddButtonText());
					button.appendChild(buttontext);
					$(button).click(function () {
						control.addNewRow();
						drawrows();
					});
					el.appendChild(button);
 
					//CREATE DIV CONTAINER FOR ENTITY COLLECT
					var div = document.createElement("div");
					div.id = "entitycollector";
					el.appendChild(div);

As you can see, there was a little more than just a DIV. The code added an “Add Row” Button to the top of the Container, add set a click event to add a row to the Control with control.addNewRow(). The rest of the code adds the button to the page, and then adds an empty DIV.

1
2
3
4
5
6
7
8
9
10
11
12
var myattributelist = control._source.config.templateControl.controls
					function drawrows() {
						$('#entitycollector').empty();
						// CREATE AN ARRAY OF LABELS FROM THE ATTRIBUTES
						var mylabels = [];
 
						for (i = 0; i < myattributelist.length; i++) {
							mylabels.push({
								caption: myattributelist[i].caption.toString(),
								name: myattributelist[i].attributeId.toString()
							});
						}

The code above gets a reference to the list of attributes that are on the Control (essentially, what the designer has added to the Screen in Oracle Policy Modelling. Then it creates an array of label texts for each attribute. This set of labels will be used in the next part of the code. The function drawrows() will perform almost all of the setup of the control.

1
2
3
4
5
6
7
8
9
10
11
12
var myrecords = control.getRows();
 
						if (myrecords.length > 0) {
							for (i = 0; i < myrecords.length; i++) {
								// CREATE A CONTAINING DIV FOR EACH ROW
 
								var rowdiv = document.createElement("div");
								rowdiv.id = "rowcontainer" + i.toString();
								rowdiv.setAttribute('data-rownumber', i.toString());
								rowdiv.setAttribute('style', 'background-color: lightblue;');
								rowdiv.setAttribute('data-instancename', myrecords[i][0].instance.toString());
								$("#entitycollector").append(rowdiv);

This section creates a new DIV for each row of the “records” or instances of the entity. The rowdiv also uses HTML attributes to store useful information about the row such as the instance name, which makes it easy to find things later on either in the HTML source or in jQuery.

Drawing the Inputs

The final part of the code for today looks at drawing the input boxes, check-boxes and other data entry items.

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
var attrLabel = document.createElement('label');
// FOR EACH LABEL
for (j = 0; j < mylabels.length; j++) {
var myId = myrecords[i][j].id.toString();
var attrLabel = document.createElement('label');
attrLabel.setAttribute('for', myId)
var attrLabelTextNode = document.createTextNode(mylabels[j].caption);
attrLabel.appendChild(attrLabelTextNode);
 
//ADD PROPERTIES TO THE HTML INPUT
var myattributedatatype = myrecords[i][j]._source.config.dataType;
 
switch (myattributedatatype) {
 
case "boolean":
var attrInput = document.createElement('input');
attrInput.setAttribute('type', 'checkbox');
break;
 
case "number":
var attrInput = document.createElement('input');
attrInput.setAttribute('type', 'number');
break;
 
case "text":
var attrInput = document.createElement('input');
attrInput.setAttribute('type', 'input');
attrInput.setAttribute('data-datepicker', 'false');
break;
 
case "date":
var attrInput = document.createElement('input');
attrInput.setAttribute('type', 'input');
attrInput.setAttribute('data-datepicker', 'true');
break;
 
}

So what is happening here? In the first part of the code, we are setting up the labels by adding the text node to build the appropriate UI. Then we switch through a variety of different data types – note that we have not covered them all, just the core types – and how they will be built in HTML. The date type, for example, is going to use jQuery UI date picker so the type is set to input not date as you might have thought (to take advantage of modern browser support for that input type) but the support is patchy and the limitations many. So it is going to be a simple input but with a jQuery UI element bound to it.

The Boolean uses a check-box and the Number uses number : so we can experiment with that UI experience.

Continues in part two of our Custom Entity Collect Extension in Oracle Policy Automation investigation. If you are looking for more information, the official documentation is to be found here.

Oracle Policy Automation Embed Website in Interview End

Oracle Policy Automation Embed Website in Interview

Oracle Policy Automation Embed Website in Interview

This request comes up quite often, at least often enough that I feel the need to mention it today. The example we are going to use is to embed the OPA Hub Website in an Oracle Policy Automation Interview. In addition we are going to pass an attribute to the website so that it performs a search for us. So, let us start our tutorial “Oracle Policy Automation Embed Website in Interview”.

Now, I am sure many of you are old enough to have spent years trying to avoid IFRAME integrations in applications : Siebel, SAP, they all do it or have done it at some point in time, and they are awful for the most part – whether it be from an accessibility, SEO, browser restriction or other perspective. So here are our goals for this mission:

  • Don’t use an IFRAME
  • Add the Website in a way that does not destroy the look and feel of the Interview
  • The Website must actually function properly

The steps to create this Project are shown below. You should be aware (and not be surprised) that this will not work well in the built-in embedded Browser in Debug Mode, so run Debug mode using Ctrl+Debug or deploy the Project to see the final results.

Oracle Policy Automation Embed Website in Interview Pre-requisites:

A New Project called “Oracle Policy Automation Embed Website in Interview” or something shorter.

Create a global attribute with the text the subject with a name of subject.

Create a new Screen to ask what is the subject. I suggest a Drop-down list with the Values “Siebel Integration, JavaScript Extensions,Service Cloud”.

Create a second Screen to display the Website.

  1. Create a label, using the name  of  the subject to display the chosen subject.
  2. Place this inside a Container
  3. Make sure you add a Property for the Container, naming the Object.

By now the Screen should look like this:

Oracle Policy Automation Embed Website in Interview Design

Now we come to the code. This is quite simple,although we will also need some CSS to make it look right. Add a JavaScript file and a CSS file to your resources folder for this Project. The explanation is after this code, which is as always provided for educational and investigative purposes only:

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
/**
 * Richard Napier The OPA Hub Website April 2018
 * Educational Example of Custom Container with a Website inside
 * I will remember this is for demonstration and educational purposes only
 */
 
OraclePolicyAutomation.AddExtension({
	customContainer: function (control,interview) {
		if (control.getProperty("name") === "xWebsite") {
 
			return {
				mount: function (el) {
					var myDiv = document.createElement("div");
					myDiv.setAttribute("id", "mySpecialDIV");
					document.body.appendChild(myDiv);
					$("#mySpecialDIV").width(900);
					$("#mySpecialDIV").height(600);
					var mySubject = interview.getValue("subject");
					$("#mySpecialDIV").html('XXXXXX'+ mySubject + '">');
				},
				update: function (el) {},
				unmount: function (el) {
					var myDiv = $("#mySpecialDIV");
					myDiv.remove();
 
				}
 
			}
		}
	}
});

Oracle Policy Automation Embed Website in Interview Code

In the code above, here are the salient points.

Lines 13 to 17 create a DIV and insert it into DOM, appending it to the body of the document.

Line 18 retrieves the value selected by the user on the previous page that is present in the Container as a label.

Line 19 is the most important one. Notice the “XXXXX”. Replace this with the website and any URL construct you need. For example, replace it with the following:

<object data="https://theopahub.com/main/?s=

The code viewer didn’t correctly display that part. Insert it exactly as shown, so that you are concatenating the URL with the user selected subject. The key point here is the use of the object tag rather than an nasty IFRAME. Thanks to Stackoverflow!

The rest of the code just tidies up when the unmount happens.

Oracle Policy Automation Embed Website in Interview CSS

The CSS is quite important here, to ensure that the embedding is seamless. Add this CSS code to your CSS file.

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
object {
    height: 100%;
    width: 100%;
}
#mySpecialDIV {
	float: left;
    margin: 0px;
	-webkit-border-radius: 10px;
	-moz-border-radius: 10px;
	border-radius: 10px;
	background-color: #404040;
}
html
{
    border: 0px;
    margin: 0px;
    overflow: hidden;
    padding: 0px;
}
body
{
    border: 0px;
    margin: 0px;
    overflow: hidden;
    padding: 0px;
}

Let’s take a look at the CSS. We use styling to position the DIV, as well as styling to ensure the object tag uses all of the available DIV. Finally we use some tricks to eliminate overflowing content and remove the horizontal scrollbar.

Oracle Policy Automation Embed Website in Interview Debugging

As mentioned earlier, this may be best tested in the Browser, not in the Debug Embedded Browser, so make sure you start with Ctrl+Debug.

The first screen will be straightforward:

Oracle Policy Automation Embed Website in Interview 1

The second screen will display and if your Internet connection is slow, you may have time to witness the two stages of display:

Stage 1 : Show the styled DIV that has been added to the Screen. Of course you don’t have to use this colour, I just wanted to use it for positioning and effect.

Oracle Policy Automation Embed Website in Interview DIV

Stage 2 : The embedded Website is displayed. The embedding is seamless (nice colour scheme!).

Oracle Policy Automation Embed Website in Interview End

  1. Notice that the attribute value has been passed to the OPA Hub Website and a search has been performed for you. The site is fully functional and can be accessed from the Interview Window.

Have a nice day! (The PDF is in the OPA Hub Shop).

Custom Entity Container with JavaScript Extensions Revisited

Custom Entity Container with JavaScript Extensions Revisited

Assiduous readers will recall that we followed a series of adventures in Entity Container extension some time ago, from a basic tool that worked only in Debug Mode to a more interesting and robust concept that worked once deployed. For reference those Custom Entity Container with JavaScript Extensions articles can be found in the following links

So why come back to this example? For several reasons it seems appropriate to talk again about Custom Entity Container with JavaScript Extensions. Firstly, it is something that is often coming up in classes or on customer sites. So, subjectively I want to talk about it. Secondly, it is a great way of learning the ins and outs of the JavaScript extensions in general.

Yesterday, I was mad

I noticed that the PDF generator I had used for the third (and most interesting and useful example) had pretty much destroyed part of the file : specifically a couple of lines were duplicated and others were truncated. So it is time to revisit this, if only to correct the errors (I have uploaded a more up-to-date file, so that some of the errors have gone).

So let’s set the scene first. We want to display some entity instances. These are generated in my case by an Excel Spreadsheet. They contain one entity, the insult and this entity has three attributes : an Id number, the text of the insult and an insult level – a numeric categorisation of the insult. The higher the number, the more severe the insult. The insults themselves come from Tintin, or more precisely Captain Haddock.

There are no conditions in this Excel file, so the instances are created. There are 240, so we need a good display of our instances. The default display is too long, with no useful scroll bar. We want to replace this with jsGrid, a lightweight jQuery grid. We want something that replaces the style on the left with the style on the right:

Custom Entity Container with JavaScript Extensions Revisited

We would like

  • A grid format using little space
  • A scroll bar
  • A pagination control

The visual elements will be provided by jsGrid, a lightweight JavaScript control. We are also going to set the bar a little higher than last time. We want to have a dynamic filter of the grid, so that the user can view what they want (and not always have the 240 instances on the grid).

Custom Entity Container with JavaScript Extensions Revisited 2

Note: we must tread very carefully here. We must not change the business logic in any way. We must separate the concerns and provide purely UX elements in our JavaScript extension. But given this is inferred data, I think a little filtering is fine, as long as the underlying relationship is not tampered with.

The code would be based on the standard template, so I will simply put it here, in all of it’s quickly-strung together glory, so that you can read it, learn about it, clean it and make it industrial. As I always like to make clear, anything I post here is strictly not-ready, big-picture, here’s-an-idea for you to look at and make your own. This Custom Entity Container with JavaScript Extensions example is available on the OPA Hub Shop for download, as usual. It is listed as example #3 of Custom Entity Container.

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
/**
* Richard Napier The OPA Hub Website April 2018
* Educational Example of Custom EntityContainer Extension
* I will remember this is for demonstration and educational purposes only
*/
OraclePolicyAutomation.AddExtension({
customEntityContainer: function (control, interview) {
//console.log("Get Array Reference");
if (control.getProperty("name") == "xEntity") {
var entities = interview._session.config.data;
var entityId = "entitypublicname";
var entity;
for (= 0; i &lt; entities.length; i++) {
entity = entities[i];
if (entity.entityId === entityId) {
break;
}
}
return {
mount: function (el) {
//console.log("Beginning customEntityContainer jsGrid");
var myDiv = document.createElement("div");
myDiv.setAttribute("id", "mySpecialDIV");
//console.log("Styled customEntityContainer");
el.appendChild(myDiv);
var myFlatList = [];
var myObject;
for (= 0; i &lt; entity.instances.length; i++) {
myObject = new Object();
myObject.insult = entity.instances[i].attributes[0].value.toString();
myObject.insult_text = entity.instances[i].attributes[1].value.toString();
myObject.insult_score = entity.instances[i].attributes[2].value.toString();
myFlatList.push(myObject);
//console.log(" Flattened the list - item " + i);
}
$("#mySpecialDIV").jsGrid({
width: "80%",
height: "400px",
sorting: true,
paging: true,
pagelndex: 1,
pageSize: 10,
pageButtonCount: 10,
data: myFlatList,
fields: [{
name: "insult",
type: "text",
width: 20,
title: "id"
}, {
name: "insult_text",
type: "text",
width: 150,
title: "text"
}, {
name: "insult_score",
type: "number",
width: 20,
title: "score"
}
],
controller: {
loadData: function (filter) {
return $.grep(myFlatList, function (item) {
return item.insult_score === filter.insult_score
})
}
}
});
//console.log("Finished customEntityContainer");
},
update: function (el) {
var myslidervalue = $("[role*='slider']").attr("aria-valuetext");
$("#mySpecialDIV").jsGrid("search", {
insult_score: myslidervalue
}).done(function () {
//console.log("filtering completed with slider value " + myslidervalue);
});
},
unmount: function (el) {
var myDiv = $("#mySpecialDIV");
myDiv.remove();
//console.log(" Removed the customEntityContainer ");
}
}
}
}
});

So now let’s look at the key elements (don’t forget to download and place jQuery and jsGrid files into your resources folder) :

Line 11 – this should be replaced with the name of your entity (not the text, but the name or XML tag as some call it). We are going to search amongst the entities until we find yours.

Lines 30 to 35 –  the code extracts your entity and pulls out three attributes from the entity. Note of course that these three attributes need to be placed in your Interview Screen, inside the Entity Container, for this data to be available. Essentially the extracted information is made into a JavaScript object, and the object added to an array.

Line 38 – this is the start of the jsGrid code.

Line 47 – this is the definition of the three columns of data in the table and how to display them.

Line 66 – this is the custom filter function which will hide any instances that do not have the selected score.

Line 77 – this is where we obtain the value of the slider and we refresh the table to only show those records using the filter function.

Thanks to the Madrid crew for their suggestions. In the next few days we will look at another Custom Entity Container with JavaScript Extensions example, this time with a dynamic chart using the same principle. Please note as usual that for best results when debugging, use Ctrl+F5 to debug in a decent browser.

The OPA Hub Snap Poll Results

The OPA Hub Snap Poll Results

The OPA Hub Snap Poll Results

As you know, the OPA Hub Website runs short-term polls or “Snap Polls” in an effort to collect and share information about Oracle Policy Automation that may hopefully be of value to the Community. The OPA Hub Snap Poll Results concern the question we asked in March 2018, specifically “Are you going to be using the new JavaScript Extension in your OPA Interviews?”.

The most recent versions of Oracle Policy Automation have pretty much consolidated JavaScript as the client-side platform for delivering just about any visual changes you might wish for. Many of us are also pretty hopeful that the JavaScript library in interviews.js is a forerunner of a future REST client, and hopefully the basis for some sophisticated integrations as well.

Of course there are other avenues of development of Oracle Policy Automation, notably the experimental RuleScript, based on the output of the Oracle Labs and the graal library. Anyway, The OPA Hub Snap Poll Results were quite definitely in favour of the JavaScript extensions. You can find the results below, and I have included a link to a dynamic version of the graphic hosted by our friends at easel.ly.

 New OPA Snap Poll

As the Snap Poll on the subject of JavaScript has now closed, a new Snap Poll has been opened, this time in an effort to get more information about the needs of the Community in respect of training and advanced workshops. Please take a moment to answer the OPA Hub Snap Poll on this subject.

You’ve got to be in it, to win it

A reminder : when we close this Snap Poll, one lucky voter will get a free copy of Getting Started with Oracle Policy Automation 2018 Edition, so don’t hesitate to vote today. The Snap Poll will close on the 31st April 2018, and results will be published on this website soon afterwards.

 

OPA 12 - Oracle Policy Automation and Siebel Innovation Pack 16 Checkpoints 2

Oracle Policy Automation and Siebel Innovation Pack 16 #5

Oracle Policy Automation and Siebel Innovation Pack 16 #5

So, following on from the previous post in this series, where we looked at testing the Load and Save operations using Oracle Policy Automation and Siebel Innovation Pack 16 (as opposed to simple SOAP UI testing which is good, but will only get you so far), this post takes a slightly different turn and investigates two operations that are not strictly speaking required to be implemented.

The definition of the Oracle Policy Automation Connector Framework contains a boolean tag as to whether checkpoints are enabled in a given Connection. And these checkpoints are the subject of this post. Firstly, what is a checkpoint?

A checkpoint is a point in an interview, after which the contents of the Screens (Controls, for example data you have entered) is saved in a specific format, namely as an encoded Base64 string. This string of course needs to be saved somewhere : for example in a table in your Siebel database. Once it is saved, it can be used to open the Interview once again, through the integration between Oracle Policy Automation and Siebel Innovation Pack 16, and the session can be resumed. Obviously this has a great advantage of being simpler than trying to save all the data you have into Siebel Business Components, especially given that the Interview might not be complete yet.

So you can think of checkpoints, and their two operations SetCheckpoint and GetCheckpoint, as sort of temporary saves. When you save the checkpoint you do so with an identifier (so, an id as in previous operations). But the process of SetCheckpoint and GetCheckpoint is completely separate from Load and Save : they are two different mechanisms to handle two different business needs.

Here is a screenshot of what it looks like residing in a Siebel Table, which you will learn more about in the videos and presentation:

Oracle Policy Automation and Siebel Innovation Pack 16 - Checkpoints

The use of the Siebel Row Id means that it is relatively simple to create an Applet that sits on top of the Business Component, because you might use it as a Child Applet with the Obj Id Val as your key to finding stored sessions for your Customer or whatever it is.

The usage of these stored sessions requires a slightly modified URL to open the Interview, which you will learn about in the videos as well. In both cases (starting or resuming an Interview) a Symbolic URL, or a JavaScript embed, will be enough to call the Interview from the Siebel side.

From the Design perspective, implementing Checkpoints in your Screens is very simple, assuming you have selected a Connection that supports them. For example, the screenshot below illustrates the options available when designing the Interview. Note how you can select the relevant Screens or all of them. Selecting all Screens ensures that the Base64 string is pushed to the storage table after each Screen.

OPA 12 - Oracle Policy Automation and Siebel Innovation Pack 16 Checkpoints 2

Now that you have the details of this new part of the Oracle Policy Automation and Siebel Innovation Pack 16 integration, here are the videos to help you go further, and the links to the other parts of the series.

In this topic, learn about the two optional (but very useful methods) called Get and SetCheckPoint. This presentation explains the prerequisites and pitfalls.

Presentation

In this topic, learn how to implement these methods in Siebel, build them into your Oracle Policy Automation Project and how to test and verify their functionality.

Implementation

Links to Oracle Policy Automation and Siebel Innovation Pack 16 Series

Next…

In the next part of this series we will look at other Services available to Siebel developers in Oracle Policy Automation and Siebel Innovation Pack 16.

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation #2

Guest Post : Object-Oriented Design Patterns and Oracle Policy Automation #2

In a previous post by our guest writer Dr Jason Sender, he investigated improvements in Oracle Policy Automation rules by applying some of the principles of refactoring, and then he began to discuss Object-Oriented Design Patterns and Oracle Policy Automation, and their application in real-world contexts.

As before, this third article draws on the work and publications of Martin Fowler, which we discussed in the previous post, those of Joshua Kerievsky from his highly regarded book “Refactoring to Patterns”, and the ground-breaking work on design patterns called “Design Patterns: Elements of Reusable Object-Oriented Software”, which had four authors known collectively as the Gang of Four (GoF).

Before studying some further examples of patterns and their application to Oracle Policy Automation, it is probably wise to step back and take a broad view of the context. Computer science is often defined as dealing in abstraction, and software engineering as managing complexity, and the connection is that only by considering different parts of programs and systems as abstract concepts are we better able to manage complexity.

Object-Oriented Design Patterns and Oracle Policy Automation in Context

To put it in terms more related to our daily jobs, Oracle Policy Automation is often integrated with other systems that the Oracle Policy Automation developer does not need to understand, and can think of in abstract terms. A good example would be the Siebel CRM or Oracle Service Cloud database that Oracle Policy Automation may interact with, but about which the Oracle Policy Automation developer may not need to know anything – beyond understanding the available attributes for mapping and having a brief overview of the context. Abstraction is about ignoring irrelevant details, and this is often accomplished by what is a theme running through many design patterns, which is to: “encapsulate the concept that varies” (GoF, p. 54).

We often obtain abstraction in Oracle Policy Automation by using indirection (interposing an intermediate attribute) to encapsulate the attribute that varies. This allows us to “Program to an interface, not an implementation“, as the GoF (p. 18) term it, the rationale for which is that the implementation can be changed if other parts of the program only depend on the interface.

If you come, like some of us here on the OPA Hub Website, from a CRM background, you will be familiar with the concept whereby access to a CRM Object is provided through an interface, and the interface does not change even if the Object undergoes modifications (such as when using the GetMetadata Operation of the Oracle Policy Automation Connector Framework).

Although design patterns and refactoring techniques should serve the goals of reduced duplication, reduced complexity, and increased clarity, these goals can be in conflict, not just with each other, but with certain Oracle Policy Automation-specific goals. Take for example one of the stand-out benefits of Oracle Policy Automation: Policy Isomorphism. This means having the same form (i.e., you can copy and paste legislation or other source material directly into Microsoft Word, and base your rules on this and compare them side-by-side) and this is in tension with the concept of intermediate attributes (adding more attributes to increase clarity).

Object-Oriented Design Patterns and Oracle Policy Automation : Strategy and Template Patterns

With that in mind we return to another example of how Object-Oriented Design patterns can be applied to Oracle Policy Automation. The following extended example will be given to demonstrate how useful the Strategy and Template Method design patterns (which we adapt from the GoF book) could be in reducing the number of tables and increasing the flexibility of calculations. We show this extended example to demonstrate the size of the reduction in rules from applying these design patterns to Oracle Policy Automation. We start with an information collection screen and associated Boolean rules to derive values from the drop down list items:

Object-Oriented Design Patterns and Oracle Policy Automation 1

We then look at the top level goals for determining the total profit of the company, which is our main goal:

Object-Oriented Design Patterns and Oracle Policy Automation

These are then derived from three very similar tables of calculations, which are listed in succession below:

Object-Oriented Design Patterns and Oracle Policy Automation 3

Object-Oriented Design Patterns and Oracle Policy Automation 4

Object-Oriented Design Patterns and Oracle Policy Automation 5

Object-Oriented Design Patterns and Oracle Policy Automation : Implementing the Design Pattern

We can now alter this to implement our design pattern. We first create a main rule to determine the total profit:

Object-Oriented Design Patterns and Oracle Policy Automation 6

This is the Template Method pattern since it delegates a part of the algorithm – the tax factor, a newly created attribute. Then, we employ the Strategy pattern to effectively split up the tax factor into one of three algorithms (in effect, we are treating the tax factor as an algorithm and then applying Strategy to it). We do this by parameterising, based on type of company, using a feature called Apply Sheet that avoids multiply proven attributes by letting the parameter determine which Excel Worksheet applies:

Object-Oriented Design Patterns and Oracle Policy Automation 7

Then each of the subsequent tabs has a small table. As an example, here is the mining sheet. The others have identical structure and adjusted values for the tax factor.

For the Strategy and Template Method patterns, applying these design patterns has transformed our example rulebase into something much more easily extensible.

Object-Oriented Design Patterns and Oracle Policy Automation : Improved Maintenance and Clarity

If we were to create another sector (e.g., oil), it would be very easy to add on another sheet in the Excel Workbook and add it to the Apply Sheet. In fact, we could easily add another 20 sectors, whereas there would be a lot of time-consuming ‘find and replace’ work to do in the original, and we would have ended up with dozens of pages of rules. Moreover, the original algorithm had a lot of code duplication, as the same Boolean attributes were repeated in row after row in table after table.

Furthermore, if we had needed to add or remove conditions from the tables it would have taken extensive work in order to verify that each and every table was updated correctly. In the reformed algorithm, the conditions were written only once and these are easily changeable. And, we were able to eliminate three (possibly confusing) and unnecessary sub-totals relating to each of the company types. The unvarying part of the algorithm (the total revenue – the total cost) is now written once, rather than 15 times, and so it is easily changeable.

Finally, our new algorithm mentions only the tax factor. This means that if all tax rates were harmonised, a single tax rate declared, or a new formula implemented that did not depend on the company type, since we have encapsulated the part of the algorithm that varies, we could just delete the Excel table and introduce a new table for the tax factor that did not mention the type of company. This would not have been so easy to do with the original algorithm.

Once again, even from a very simple set of examples, it should be clear that Oracle Policy Automation rules will benefit from the targeted application of principles from programming – in this case, the Strategy and Template Method design patterns. For more information about the ideas discussed in this article, Dr Sender can be reached using his LinkedIn profile, at the end of this article.

Object-Oriented Design Patterns and Oracle Policy Automation : Going Further

The OPA Hub and Dr Sender are currently working towards the launch of advanced training based on his work. If you are interested, please take a moment to answer the 1 question survey below (if you have not already registered for the OPA Hub you can do that here before you answer). Thank you!

What kind of advanced OPA training would you be interested in attending?

Oracle Policy Automation Free Quizzes to Prepare or Test Yourself

Oracle Policy Automation Free Quizzes to Prepare or Test Yourself

Oracle Policy Automation Free Quizzes to Prepare or Test YourselfThe OPA Hub Website, alongside the articles, job lists, ecosystem directory and video gallery, also maintains a number of fun, free and interactive quizzes for anyone who works with Oracle Policy Automation. Oracle Policy Automation Free Quizzes to Prepare or Test Yourself can be found on the menu or, read on for more information.

These quizzes are accompanied by a Leaderboard so you can compare your own score to the best in the world. See how high you can get on the leaderboard! Here are some quick links to the different quizzes. They all have a mixture of categories and topics, and are a good mixture of easy, hard and trick questions just to keep you on your toes. To answer the questions you will need to have worked with Oracle Policy Automation and some of the questions might be easier to answer if you are a regular reader of this website, but anyone with experience will be able to make a good job of it.

Join the 286 members of the OPA Hub Website and try one out today.

Oracle Policy Automation Free Quizzes to Prepare or Test Yourself : New Quiz Added

And today is a special day since we have just finished making some updates to the existing quizzes and added another one, which means that today there are six Oracle Policy Automation Free Quizzes to Prepare or Test Yourself which means 60 questions (all different of course) and each quiz of 10 questions is against a time limit as well, so you can really put yourself in the driving seat for your next interview or examination.

Oracle Policy Automation Free Quizzes to Prepare or Test Yourself are just part of the picture of course : we encourage all Oracle Policy Automation consultants to get trained at Oracle University. As of today there are two courses that cover version 12 of Oracle Policy Automation :

  1. Introduction to Oracle Policy Automation (1 day)
  2. Oracle Policy Modelling for Policy Experts (3 days)

To complement these offerings, we have a variety of Oracle Policy Automation workshops available.