Alright, so we were only kidding. The previous post was not the last in this series. This one is, we promise. As the Oracle Intelligent Advisor universe continues to evolve, and the tools and concepts also are enhanced, it is a valid question to ask “What of all the investment and time I’ve spent doing version 12 projects?”. Use the Migrator to Flow JSON is probably on your mind.

The first answer ( and I must stress these are my own, personal answers) is of course “Nothing changes.” I’ve lived through massive evolution with other products that I work with, and the fundamental skill set has never changed. You might need to be technically trained on product X instead of product Y, but the important things that make a difference are an enquiring mind, lots of real world experience and humility. So as we look into the crystal ball, we can say – again my own opinion – that the support and development of the Oracle Intelligent Advisor by Oracle Corporation has so far been unfailing – and frankly has surpassed what I was expecting by a very wide margin. I have no nightmares about this – version 12 will continue for a very long time, and there are no plans to remove it. The new universe of Flows, Flow Engine API and Flow Schemes is very new, immature (in the real sense of the word) and does not have anything like the feature set of Oracle Intelligent Advisor 12 for now. It is very much a work in progress. And that’s OK!

The second answer is a more prosaic one – much, as you have seen in the previous articles (part one , two, three, four, five, six), has not changed. The fundamentals are still there. New interface, new process, new names but Oracle Intelligent Advisor is still the immensely capable decision automation platform it was before Flows broke cover. The changes so far revealed make sense for the future and for customers that demand ever-more flexibility and power. This is the right way to go.

Back to the subject at hand. Anyone who wants to skill up and be ready for the next generation needs to learn about the tools and platform, of course – and one of the ways you can do that is to check out the migrator. This tool that runs with Node.js converts projects from Oracle Policy Modeling to the new Flow JSON format. Interviews and Connections are not converted given they are two areas that are evolving quite a lot. Running the migrator on a simple project from Oracle Policy Modeling and loading the result into a new Flow project by importing it, can really help your learning journey. Here is an example.

Take a simple interview project (knowing that the migrator does not handle the interview part) as your starting point. Let’s use the Example Project called Energy Saver as our first test. You will recall (if not go visit the link and watch the relevant video) that this project is a simple multi-screen interview with a stack of boolean attributes. There are no entities so it will be easy to understand. It asks a bunch of questions and find out how energy-aware you are. Various elements are hidden or shown depending on what you answer. There is an image, two numbers and the rest is pretty much boolean.

The migrator tool is installed and runs on Node.js. It has a variety of optional or required inputs for the command line. Basically you need to know:

1. Where the OPM project is stored on your hard drive. This is the main directory, and you need the subdirectories with the Rules and the bin folder available as well. Recall that the migrator does not migrate the interview, just the rules.
   
2. Every flow needs a Flow Scheme as we discussed previously, so you need to have two choices. Either create an empty Flow (with an attached Flow Scheme) on the Hub and export the Flow JSON to use it as a “template” OR just add the Flow Scheme later. If you choose the first option, any rules extracted from EnergySaver would be added to the JSON file of your “Empty project with a Flow Scheme assigned”. In the second option you would get a warning when opening the new Flow and have to select a Flow Scheme at that point, The video demonstrates the latter – creating the Flow and adding the Flow Scheme once it is imported.
   
3. Optionally you can also add a settings file if there are any specific settings you want to impose. For example, if you want to skip certain rule documents in the OPM project and not migrate them, this is where you can specify that sort of thing. We demonstrate a simple example in the video.
   
4. The new name you want to give to your new JSON file and where to save it.

So the following might be our command line:

node build/migrate.js "C:\Users\Richard Napier\Documents\Oracle Policy Modeling Projects\EnergySaver" --template "c:\temp\myblankflow.json" --settings "c:\temp\mysettings.json" --outproject "c:\temp\energysaverflow.json"

Let’s see it in action. Navigate to wherever you installed the migrator application, bearing in mind there are two subfolders and you need to be in the migrator subfolder. The process is pretty straightforward and the result is a Flow Project with the rules migrated (with some restrictions where exact functionalities do not match) and a whole bunch of errors because input fields are not collected. Basically most of the errors will be because of one of the following:

1. The attribute was not copied into the Fields of the Flow
2. The attribute was copied but it is missing a list of values
3. A calculation does not make sense because it used a field value that is referenced in a new way
4. Certain features (covered in the excellent online documentation) are not mappable to Flow features yet.

So now let’s see how that works out in real life. The files were generated by migrator in the video below.

Now the work can continue in the web authoring platform. A large part of that will feel very familiar – creating new pages and adding Questions and filling in labels and so on. There are a few differences – needing to add visibility rules to labels is done in a slightly different but very similar way, and not all the attributes that existed in the original project got carried through. Other things to watch out for:

1. Attribute text can contain () parentheses but not in Flows. So you will see some fields with underscores in the demo video below. That can be fixed using one of the options in the options.json we mentioned.
2. Dropdowns use an inline list, which essentially is creating an object behind the scenes to store the values and the display values. Rules that use these values need to reference them using a different syntax – list : option value. The option name will be the value entered when you create the list.
3. Visibility where you want to say something should be shown if a field is false, must use the Not() function as there is no “negation” possible.
4. There is no image control, so in the demo we used a custom Flow Scheme component that we talked about earlier in this series to display an image.
5. Using substitution in a label is slightly different since the field list becomes available after clicking the (X) icon in the label.
6. When using Bold, you have to select all the characters you want to Bold. You cannot just “bold” a label
7. If your label contains HTML, select the HTML Content switch to be able to use it.

So let’s see what that brings in terms of the work that gets done. The following is an accelerated video that walks through the various steps to get the Flow running. Unlike the video above there is commentary from me this time.

It is impossible to underestimate the learning you can glean from such an exercise, if you have never done it before.

See you next time. We’re going to take a short break now, but we will be back before the end of August. We won’t win prizes for editing this video, some of the jumps are quite, jumpy. We had an issue with the CPU usage, so apologies for the odd glitch.