In this, the most consequential, part of our series unveiling the next generation of web authoring custom-rendered interviews, we look at the functional and technical steps to create an interview Flow (which, for the purposes of comparison, we can think of as a web interview).

This article is quite long so it has been broken into two parts. It uses an example Project which you probably already know – the OPM version of the Student Benefits Example Project was already the subject of an article, and this example is a modified version for web-authoring in the Oracle Intelligent Advisor Hub.

Just to be complete, here again is the set of elements that we’re calling the next generation of rule authoring and interview authoring:

This “new world” is made up of:

• Decision Services
• Flows (the subject of this article)
• Flow Schemes
• Flow Engine API

Go with the (interview) Flow

An interview Flow, as we mentioned above, is the concept that is somewhat aligned with the interviews we know today. But to deliver one of these in the web authoring environment requires a new set of tools. In particular, we need a choice of rendering platform. Recall from an earlier article the new structure of the stack:

So let’s unpack all of what we just said and get started with our examination of this project.

Within an Oracle Intelligent Advisor Hub where the new limited-availability functionality has been enabled, there are now different project types, two of which work together (the Flow Scheme and the Flow), and one of which uses a common interface (Decision Services) to create non-interview projects:

Flow Scheme Details

The first thing we are going to do is import a ready-built Flow Scheme and take a look at it. From the usual menu in the Hub we import the Project JSON file. Let’s see what’s in the Flow Scheme:

In the Controls section, we can see that all of the standard template Controls have been included. But there are also some extra Controls in there. Heading for example, or HTML Block. There are four items that have been added to this Flow Scheme. This maybe helps you to understand the role a Flow Scheme will play – defining, for Flow authors, easy to use controls and other items that essentially define their “palette of tools and data”. Maybe you will have, in the future, one team working on Chat applications integrating with Salesforce, and another working on Flows with Oracle Visual Builder integration. So you would expect the Flow Scheme to be different – available Controls, available input and output data and so forth.

Looking at one example in more depth, the Heading Control:

We can see that the Heading Control is a label, with a different name for the “palette” and an integration id that the rendering code can use to reference it. Plus, we can see that a custom property has been added “header-level”. The author can set the heading level at design time, and the rendering code can read that and decide what to make it look like (bigger text, different CSS Class or whatever). So this Control has been created for the purpose of making it easier for the author to work with abstract concepts and not have to worry about the actual rendering.

Still in the Flow Scheme, we can see some data elements have been added:

So the Flow Scheme, to recap, is the definition of the environment that a rule author will work in, and at the same time a definition of many technical elements (lists of values, data mapped in and so on) that represent the environment that the web interview will be executed in by our renderer.

So let’s take a good look at the different elements of the interview as it appears in the web authoring interface, with the Flow tab selected. In this screenshot the interview designer has begun building a page:

1. On the left we can see the interview designer can access the controls palette to build what are known as Sections, Page Groups and Pages of the interview.
2. Note that the Flow Scheme we are using included some customized elements so they appear here too.
3. The vocabulary is no longer Screens and Stages. The main Section represents the wrapper for everything in the Flow, organized into Page Groups and Pages.
4. Most of the simple editing is click and edit, or drag from the Control Palette onto the Page.
5. Notice the slightly grey / green section – that’s substitution text.

In the above second example, you can probably see the substitution text more clearly. Note the message at the top relating to the elements defined in the Flow Scheme (see the last article) that included inbound data. If we switch to the Data View:

The left-hand side now shows a variety of information :

1. Global input data inherited from the Flow Scheme definition (note my cursor is hovering over the existing student’s ID which we saw in the Flow Scheme)
2. Fields collected in the Flow you are building
3. Fields inferred in Rules in this Flow
4. Things like Lists of Values and other Field details

As you would expect, switching to the Rules tab takes me to the Rules that define the logic of this Flow. If you have been following our training on Decision Services then you will be very familiar with this new user experience. This is the new Rule Editing, Debugging, JSON-testing and deploying experience.

Both of these tabs use the same menu-driven user interface – so you will find options to commit, deploy, download strings for translation and more in the menu.

Of course, once you’ve gotten your interview flow into shape, you are going to want to run it. And that’s what the Run button is for.

In order to do things right, we should ensure that we have the following software installed whereever we intend to run this Flow:

1. Node.js, downloaded and installed – this will be our platform for our rendering code and accessing the Flow Engine API library to ensure our interview flow is displayed
2. Visual Studio Code, the lightweight code editor for debugging and writing code

You will recall from the previous article that a Flow Scheme defines the names of controls that appear when designing a Flow, and the Flow Scheme also defines how those controls appear to any JavaScript or TypeScript code that interacts with the Flow Engine API to render the Flow. So when we click Run, it needs to know where to get our code ( on our Node.js installation) and that code will leverage the Flow Engine API for objects and methods that give us information about our Flow.

You will also remember from last time that in a Flow Scheme, Controls have integration Ids as well as a friendly Name. The integration Id will be used in the rendering code, and the Name is shown in the Flow Authoring interface.

So we are ready for the final step – running our interview! See you in the next part of this series when we go into the details of how this will run.