Welcome to the OPA Hub!


Category Archives: Relationships

Fun with Aliases and Strings #2

Fun with Aliases and Strings #2

Returning to the ” Aliases and Strings”  theme of the previous post, where we looked into an example of String concatenation. Just a reminder, in the previous article you created the entity model and set up a couple of relationships, before using a rule to decide if the ticker tape instance is a member of a relationship called  the next ticker tapes.

So here is the continuation of the document you saw in the previous steps:

Aliases and Strings #2

The first part should look reasonably familiar, since it builds on the example with the next ticker tapes. But is uses the second relationship, called the closest ticker tape. Note the wording closest ticker tape not ticker tapes. We are aiming for the closest one, or if you prefer, the next one in line. So for ticker tape number 3, the closest would be number 4.

Dodgey Ticker

We again use an alias, but things get a bit sticky in the following parts. Where did the further ticker tape come from? Well, perhaps unsurprisingly, it’s another alias. You see, we already used the other ticker tape in the conclusion so we need to use another word : in this case further was my personal choice, but it could have been another word that meant something in this context. So by now we have the following, expressed in conversational style :

Compare ticker tape A (with other tapes, let’s say B, C and D). B,C or D will be called the closest ticker tape if the following is true.

  1. B,C or D have an ID that is higher than the ID for A
  2. Using the next ticker tapes as your starting point (so, B C and D)
  3. Compare them (so B compared to C, B compared to D etc) to this rule
  4. Is B’s ID is less than or equal to C (for example)?

So we end up with the ticker tape that is in the next ticker tapes AND has an ID that is less than or equal to the other next ticker tapes. So it is the closest one.

I’m reminded of this excellent conversation from Monty Python since it can get a bit confusing at first:

video

The final rule concerns whichever ticker tape has the longest string. And that string is what you are about to create, for each and every instance of your entity.

We’re coming with you!

You will generate a string of text for each of the entity instances (so, for each of the ticker tape instances). And this string will be the driver of a logical loop.

Firstly, let’s set your scene and remind of the context:

  1. “Text 1”
  2. “Text 2”
  3. “Text 3”

Each ticker tape has a text message, for example “Text 1” . This message should be concatenated with the other text messages to form a long “final” string. Each should have a comma inserted between them, into the final string, and of course a “.” at the end. Just to make a nice tidy “final” string. It might look like “Text 1, Text 2, Text 3.”.

Aliases and Strings #2

So each instance has a text string, and a “final text”. The “final text” will be the ticker tape text string concatenated with the closest ticker tape’s text string, plus a comma if required – for example if there are no “next ticker tapes” for a given tape, it’s because we have reached the end of the instances (number 4 , if there is no number 5).

The following attributes give us the numbers used in the table above:

Aliases and Strings #2

And the final (final) global attribute:

Final String Result

Aliases and Strings #2

In the next part of this series, there will be a chance to look back on the techniques, observe the warning message and generally investigate your logical loop.

Aliases and Strings part three will be with you in a few days, In the meantime of course you can read the online help here.

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!

Back to Basics Fun with Relationships

Back to Basics Fun with Relationships

The other day I had cause to discuss Relationships with an Oracle Policy Automation developer, and as a result of the discussions and the level of interest expressed in the learning curve, I thought I would share here the project that I used to illustrate some of the main concepts used when working with them in an Interview. Firstly, to put Back to Basics Fun with Relationships in context, here are the entities we will discuss :

  • Global (of course)
  • the car
  • the passenger

The entities are in part received from another system, and look like this:

To simulate the external system in this demonstration, the data for the cars is coming from a Microsoft Excel spreadsheet which infers various vehicles. The passengers are manually entered in the Interview and then different relationships are using to construct the connections between the cars and the passengers. In this case, we need to identify the passengers in each car (which has been called the car’s passengers here), and then to specify which passenger is sitting in the front seat (which has been called the copilot here). So the car entity has the following reference relationships, both of them with the passenger but of different cardinality.

Back to Basics Fun with Relationships 3

When we look at the first two Screens there is not much to report. The first displays the cars and the second gets the passengers.

Back to Basics Fun with Relationships Cars Back to Basics Fun with Relationships Passengers

The third Screen is where some students can go wrong. The key is to display the relationship (the car’s passengers) . In the case shown, a label has been added to display the car name. Notice how the choice of display is limited to Checkbox because of the cardinality of the relationship. This makes for a situation where the user can choose the passengers and of course a passenger can only be in one car. Selecting the same passenger for two cars produces an error (as it should, even if the error message is generic).

Back to Basics Fun with Relationships Choose Passengers

  1. The relationship is added to the Screen
  2. The selection control is displayed
  3. Only Checkbox is available

The Screen looks like this in the Debugger:

Back to Basics Fun with Relationships Selecting Passengers for Cars

Finally, the fourth Screen will allow the selection of one of the passengers to be assigned as the front seat passenger (a.k.a the copilot). The Screen is displayed below and the key areas highlighted:

  1. Again we add the relationship to the Screen
  2. The cardinality means the default display option is a Drop-down, although others are available in the Toolbar this time (fixed list or radio buttons). I wish these were customizable using Control Extensions but they are not…as of 18A.
  3. The display will allow you to select a copilot, and filtering the data ensures that only passengers of the correct car are available. In this way, the first relationship (the car’s passengers) drives the second (the copilot).

The Screen looks like this in the Debugger:

Back to Basics Fun with Relationships Copilot

Finally there was a requirement to associate the copilot with the car in a more direct fashion. Specifically, the car entity had attributes to contain the name of the copilot. The basics (not complete) of this are shown below:

Back to Basics Fun with Relationships Mapping

So the car has a front seat occupant boolean attribute and the value is retrieved from the passenger entity and the copilot relationship and copied into the car attribute. The relationships and the entities allow us to retrieve data in the structure and place it in the car.

Back to Basics Fun with Relationships Data Tab

Hopefully this example will let you imagine how relationships can be used to enhance your Oracle Policy Modelling. I hope you enjoyed this Back to Basics Fun with Relationships post. As always the official Oracle Policy Automation documentation can be found here.