This post continues on from the series about retrieving information from REST APIs (in this case Oracle B2C Service) to display the data in the form of Custom Options or Custom Inputs. The situation this time is that we want to use one of the standard hierarchies (for example Service Categories or Service Products) in Oracle Intelligent Advisor.

Let’s compare how they are displayed in the source application and how they appear once mapped into Oracle Policy Modeling.

On the left, the Agent Desktop of Oracle B2C Service Cloud. On the right, an attribute whose Type has been mapped to the Value List. They look the same, right? Not really. The sub-optimal part of the Oracle Policy Modeling and Interview experience is that the user can select any value at any time – it’s a sort of pseudo-hierarchy. It is not a parent and child Value List combination. It is a flat list, with a specific display style. The Value List can be super long and not very friendly.

What can we do to solve this? Well, if you think about the REST API for Oracle B2C Service Cloud, you will know that Service Categories or Product Hierarchies are available for retrieval. Let’s look at a GET for Service Products as an example :

In the image above, I’ve returned all Service Products and scrolled in the Postman Response Body to show one of the products. Note the lookupName and the id, that will be very useful. Some products are child products. They have a parent. The parent, unfortunately, is not visible in the list of Service Products. It is visible if you query for a single product however you will see the relevant section regarding the hierarchy:

If a parent is present, this block will be populated:

You can see above that I am getting information about product id 54, and the parent is 11. If there is no parent, you would see instead this block, with parent set to null.

This is just a simple example with a two level structure. Ultimately you could recursively search for

• Any products without parents. These are the top level
• For each child product and get the parent.
• If the parent is not in the top level product list, search again for the intermediate level(s) repeating until you have the entire structure.

The downside for all of this is the number of calls we would have to make to retrieve the hierarchy. But when finished, we could load it into and Entity Collect.

For our demonstration, we will only cover a simple parent-child relationship. We want to display Product Categories and Child Products. We need to consider what we cannot do, before we move forward.

We cannot create Value Lists “on the fly”. There is no API or Extension format that would allow us to do that, unlike the Connector Framework. We could create a multi-level menu using jQuery UI (and in fact we will look at that in a later example). But it would be a little counter-productive to just do something that is just “visual”. We want the list of products to be part of the structure of our interview, so that we can display them, for example, several times in different ways on different Screens.

Thus one area that would be interesting to investigate is to use an Entity. So we could make a Custom Entity Collect Extension. We would have to make it an Entity Collect Extension because we want (in this case) to load in and store the products and their details so that we can display them and let the user select something, and maybe display them on several Screens. In the past we’ve created some Entity Collect Extensions for specific requirements and even built a complete one for the Consultant’s Guide to JavaScript Extensions for Oracle Policy Modeling book.

We can load the initial product list and then check for any parents that may be present. So if you have 20 products, you would need 21 calls (one for the initial list, and 20 for the products to see if there are parent products specified). When you are performing the 20 calls for the details, you can either use the standard /serviceProducts/X call or use the ProductHierarchy call. Both return the same information, the first contains more information about the product.

Once the data is retrieved into, for example, an array of objects then we can push them into our entity using

control.addNewRow()

There is a poorly / not documented template argument for this method, that you use to create the row and populate the attributes in one shot:

control.addNewRow({ "attributename" : "textvalue", "attributename" : value })

Once the data is present in the Entity, save it and you have everything you need to display, for example, the products that have parents and the products that do not:

The project itself might look like this:

Obviously you will also need to have an Interview Connection to the Oracle B2C Service Cloud set up in the Hub of your Oracle Intelligent Advisor instance so you can retrieve the products. The example uses a separate Screen to load the data – you could also put it on the welcome Screen or somewhere else, but the instances will need to be loaded before you reach your selection Screen. We can present the user with something easy to use and limit the volume of information that is displayed, whilst having a cohesive user experience.

A demonstration of this is available in the Online Store.