In this third part of our series looking deeper into the subject of Hub Authoring (the previous post is here) , we will cover the subject of Object Lists. Now, coming from Oracle Policy Modeling one might be confused by the new terminology (but you won’t be in a moment). Before we look at that,I also wanted to give some feedback about the Virtual Product Strategy Meeting that happened yesterday night European time. If you have never attended one of these sessions I do encourage you to do so – massively. They are a great way to meet others who work with Intelligent Advisor and it is always inspiring to hear customer stories from other industries and countries – most of the time the ideas can be transposed to your own context. And everyone loves a RoadMap presentation of course – last nights was no exception with some very interesting things coming hopefully in 2021.

There were a couple of things that came up during the Product Strategy Meeting – one was a general desire to have calls more often – perhaps at least quarterly if not more frequently – and maybe to have different categories of meetups – expert meetups for the rule designers, for the integrators or for other groups to get together in a safe space.

Secondly, the poll in the middle of meeting showed that while Decision Services Hub Authoring is not necessarily everyone’s objective right now, it is on the radar for most people. This kind of is borne out by our own survey that we are still collecting data for. With that in mind, we have released a first free Hub Authoring video to help people who maybe do not have much time on their hands to get a grip on what Hub Authoring actually means.

Thirdly, and this is specifc to the topic at hand – the current Hub Authoring architecture is quite open – in the sense that any Rule Author who has access to the Hub-authored project can effectively make radical changes / delete the complete contents without much control. That was one of the things the leadership team listened to carefully and took on board. That underlines the importance of these sessions – they are a chance to speak, frankly and in face-to-face real time, to the people who matter.

Anyway, back to the subject at hand. Let’s look at the Hub Authoring experience when it comes to Object Lists. What is an object list, I hear you ask. Well, let’s show you and then you can see for yourself

In a new Decision Service (the name that has been given to hub-athored projects) add an Object List. An object list is essentially an entity. You can have either input or output. In the case of output entities, they are going to be inferred. So let’s start with that idea first and work from there:

At first glance it doesn’t look like much, does it? The items= part tends to put people off. But that is precisely where we will start. Changing it to something more appropriate already it looks more familiar. This feels like a containment relationship:

So we changed the text at the top to represent the outcome of this table. Then we added some simple conditions and outcome columns. Now we need to populate our Input and Output. Just a word about that – in these demonstrations, because I am playing two roles and want to explain the entire process to you, I usually do them after the initial rule construction. But of course in real life Hub Authoring you may find they have already been created for you by someone who looks after the integration aspects of the decision service. That’s probably more usual.

Here is the setup of an Object List in the Outputs. Just a name and a string of text:

But in the second part you can see that once the object has been declared, then you can add your child attributes to the entity (sorry, I meant Object List ;). I’ll go ahead and set up the inputs (the citizen’s age and zip code) as well, in the Input dialog.

And so our decision service is ready to test :

In the above example, we can see that a young person living in the overseas territories can have 2 benefits. We have inferred two instances of the benefits. So that should clear up what Object Lists are used for, as Output. But what about input. Let’s assume that this decision service will receive input in the form of multiple citizens. So we need an object list to handle that. I’ll go ahead and add it straight to the Inputs using Hub Authoring.

And, nice Decision Services feature, I can move the existing two attributes into this Object List, saving me the hassle of deleting and recreating them.

And I can change the original rule block to run for every citizen:

Finally, I need to adjust the Output because the benefits now are essentially hierarchically no longer a child of Global, but a child of the citizens. I’ll add the citizens to the output and move the benefits so they are underneath. In step one below, I added the citizens (same text, and in this case same technical name / tag). In step two I moved the benefits to under the citizens and the result is in step three. Hub Authoring makes this easy.

Now that we have the structure in place, we can further refine it by, for example , adding a rule block that is calculated once per benefit, per citizen (which you can see in point 1) or by adding some cosmetic touches like the name of the citizen both input and output if we feel like it:

All of which gives us a very nice testable engine here in the Run screen:

Of course some of this is just for demonstration purposes but now I can add citizen, delete citizens, check the details and the benefits. Cool. Hopefully this deeper dive has given you an idea of the level of sophistication already available in the Hub Authoring. We’ll be bringing out a video if you want to follow these steps yourselves, watch out for that in the next few days on our Youtube Channel.