In the final part of our initial look at the mechanics and concepts of the new Flow Engine API and Flows in general, we look at the last major component of Flow Schemes that we so far have not mentioned. This article is all about Data Actions.

In the current, Oracle Policy Modeling generation of tools, we have become familiar with the idea that Connectors – for Siebel, Service Cloud, Salesforce, you name it – usually SOAP XML based, and more recently the loosely coupled, integration-server JSON-based generic approach. These have taken care of our load and save, our executequery and the like. On the interview side we have been getting used to leveraging the interview.fetch() capability to be able to go and get just about anything we want as long as it is REST-based and asynchronous.

So what does the new “next generation” Flow Engine API have in store for us? It has Data Actions. As their name suggests they relate to some sort of action to get or set data somewhere. An action might have input and output but it doesn’t have to – for example a data action might just be “get today’s date from somewhere” – in that case although there clearly will be an output we don’t have any input – we just get the date.

Data Actions can be synchronous or asynchronous – and it is up to the renderer to handle whatever needs to be done to make it look / handle properly. Data Actions are programmed by the developer and conform to the requirements of the Flow Engine API. The IACustomDataAction method SetReturnedData needs to provide the returned information – in the case above, the date, in a JSON object.

action.setReturnedData({
    "today": "2021-10-05"
});
session.refreshModel();

These Actions are defined in Flow Schemes so that Flow designers know what they have to work with, and don’t have to worry about how any of the stuff actually works. Here is an example of a Flow Scheme Data Action definition for a set of data returned from an application.

Data Actions can both send data from a Flow as well as return data back into a Flow. They can be used to return single values or indeed record lists. From a technical perspective for data coming into a Flow, the two methods setReturnedData and refreshModel work hand-in-hand to get the information and refresh the Flow with the data received. These Actions are “place sensitive” – so if you put a Data Action on a Page, in the middle below the label that will display the data retrieved by the Data Action, the label will be empty – since the Data Action appears below the label.

This is simple yet powerful, and allows for interesting ideas such as Actions that occur between Pages. In fact this new, broad and flexible architecture can be summed up in a single phrase that appears in the documentation online:

Data actions are potentially the solution to a much broader set of problems than database actions.

These new elements will become a very flexible part of Flow design and will continue to make it easier to separate the rendering of the Flow from the logic of designing it in the Browser. Technical stuff for technical folks, and everyone else insulated from the complexity.