Jump To : Part One / Part Two / Part Three / Part Four
As we started discussing earlier this week, in amongst all the noise and fireworks for Halloween and CloudWorld, the 22C MU2 release slipped anchor and left the harbour only a few days ago. This release contains some limited availability components that are the start of a large investment, and dare I say it a revolution in how Interviews can be rendered. Note that nothing I am saying here means that Oracle Policy Modeling is going anywhere. We can think of Web-Authoring as a new branch on the tree, not chopping the tree down and starting again. This second article will discuss the next element in the new platform and architecture list – Flow Schemes.
Having successfully mixed nautical and horticultural metaphors, let’s get down to business and firstly, remind ourselves of what this “new world” is made up of:
- Decision Services
- Flows
- Flow Schemes
- Flow Engine API
In this article we will discuss Flow Schemes. What they are and how you create and manage them. Let’s begin with an important point and a screenshot. A Flow Scheme is a type of Project – so you can think of Interview, Service and Flow Scheme as the (now) three kinds of project you will create in the Oracle Intelligent Advisor Hub.
Flow Schemes
To put it simply, a Flow Scheme defines some things that you are familiar with, and some that you are not. If you intend to create an “Interview” (which we will now be calling a Flow – at least when refering to the new Web-Authoring platform). The Flow Scheme defines the following
The language of the Flow and some basic strings and parameters relevant to debugging and runtime. You can also define specific formats of numbers and other data types that you will use:
As you can see, the Flow Scheme also defines things like the Controls and the Data model that will be in the Flow. For example here I am adding a new Field to the Data section. I specify an integration property, a display name and the default field name in flow. Some of this might sound familiar – it’s like creating a Mapping in Oracle Policy Modeling for the generic integration protocol – you specify a “technical name” or integration property and how you want it to be defined.
So all of this useful information gets wrapped up inside this Flow Scheme, up to and including the different Controls you want to have in your Scheme:
So now we need to get into more technical detail. This Flow Scheme defines the design time environment that someone will be faced with, if they create a Flow with your Flow Scheme. It’s a bit like a template that defines the palette of Controls, the input data and so on. Any Flow that is created using this Flow Scheme will have the Controls from the Flow Scheme available. I’ll use that word again – for design-time, it’s basically a template for what you can use in your Flow.
So just to be clear, when you create a Flow, you have to choose a Flow Scheme:
But there is more to a Flow Scheme than just defining the “template” for design time. It also defines the environment for the run-time Flow as well. The Flow will only be able to access the input / output data you specify, and deliver the user experience controls that are part of the Flow Scheme. If you are wondering “why?”, just look at the screenshot above. Notice that when you create a Flow, a label says “A group of questions ,pages and data actions that define a web interview, chatbot or headless data flow.” I’m sure you can imagine that building for a Chat flow will require different controls (maybe a subset of what is used in a web interview) and probably different strings, formatters and what have you. So having diferent Flow Schemes will make the designer’s job easier and define the technical parameters for the execution of the flow.
So finally we are ready to create a Flow! See you in the next article where we will examine an example flow and how it is built, along with a comparison of what you know from Oracle Policy Modeling. And yes, of course, we will be revisiting all this in much more detail in the future.