Traditional Decision Management Suites (DMS) and Business Rule Management Systems (BRMS) focus mostly on Decision and Business Rules modeling and execution. However, decisions and business rules don’t run in a vacuum. They need to consume data from internal systems, external datasources, processes, databases, documents and so on.

In some cases, data access and connectivity is almost always neglected and left to software development efforts or 3rd party orchestration.

Data Integration Requirements

The wide range of data connectivity requirements makes it very hard for software development teams to pre-build all required data adapters, create all required queries, and have results transformed and ready for decision models.

Chances are that much of the data the decision model needs is in some form of database with SQL language support. However, data may need to be connected from flat files such as Excel, CSV or PDF files. Alternatively, as is often the case in the modern age of computing, some parts of the data will be sitting behind a form of API – a REST API for instance, which can provide data about a specific customer coming from CRM platforms such as Salesforce, Dynamic356 and HubSpot.

Once the set of data is collected from various external datasources, and potentially in different formats (e.g. JSON, XML, Native objects), you need to mesh them together, validate and restructure them, and enrich them to create the context for the decision model.

Creating Decision-Ready Data

Here’s an example of a car insurance scenario designed to calculate the premium, which relies on the execution of different decisions, such as those shown in the diagram below:

Car insurance scenario based on a external datasource

Example of a decision graph with a trigger associated with a decision node called “Define Potential Theft Rating”

There are two inputs for the above model: the “High Theft probability” list coming from an internal database and “Car”, where the vehicle information is provided by the consumer of the service when the model is deployed as a service.

In the above model, the “Determine rating” requires the input of the “High Theft probability” list.

Direct Data Connection in Decision Graph

Any node in a decision graph has several types of events and triggers – After and Before the execution of a specific decision node where you can also do some extra work. These events and triggers are a useful time to load relevant data from different sources based on the needs of the specific decision node. This enables you to lazy load data rather than loading everything all at once.

When a node in a decision graph is selected, you can set the triggers in the properties windows as below:

Example of Events: The "Define Potential Theft Rating" - an external datasource - is selected in a decision graph

Example of Events: The “Define Potential Theft Rating” is selected in a decision graph.

For connecting to a database or a REST API, choose the option and fill in the necessary information, such as the URL Address and authentication.

Moreover, the pre/post execution events and triggers help reduce the flow steps that are not related to the actual business process, such as logging, sending of notifications, transitional calculations, etc…

Data Orchestration

Alternatively, you can create an orchestration around the need of your decision graph. This enables you to connect to any internal and external datasources of any types.

Drag and Drop from Toolbox to build the orchestration around the decision e.g. "Premium Calculator DRD", relying on an external datasource

Drag and Drop from Toolbox to build the orchestration around the decision e.g. “Premium Calculator DRD”

Now, orchestration gives you flexibility to build up all the steps for connecting, querying, and transforming your data with a simple drag-and-drop.

There is a large, growing library of connectors to different databases (MS SQL Server, MySQL, Oracle, etc.), applications (Gmail, Twitter, LinkedIn, Salesforce, etc.), and any file formats (Image, PDF, Excel, JSON, etc…), and any REST API endpoint.

Database Queries

With either of the options – using Direct Data in the Decision Graph or Orchestration model – chances are you will be using a Database such as MSSQL, Oracle, etc… that supports SQL language for querying data.

An example of the visual query builder that allows composing SQL queries with drag-and-drop and selecting columns, relations, and conditions without programming skills, relying on an external datasource.

An example of the visual query builder that allows composing SQL queries with drag-and-drop and selecting columns, relations, and conditions without programming skills.

The Visual Query Builder enables non-technical people to compose SQL queries visually, execute them and, perform complex filtering, define data rules criteria and parameters without knowledge of SQL or programming.

Conclusion

Traditional DMS and BRMS have long struggled with limitations connecting to various external datasources, and enabling non-technical users to take care of data requirements for business decisions.

As a result, non-technical teams, e.g. domain experts, operations professionals, etc… once they finish decisions and rules modeling, they have to rely heavily on software development and IT teams for rest of the project requirements relating to data connectivity, query building, data processing and context creation.

FlexRule X provides the ability to quickly and easily integrate data from databases, REST API services, online applications such as Gmail, Dynamic365, Salesforce as well as flat files such as XML, JSON, Excel, CSV, PDF and etc… to be simply integrated as part of the decision automation efforts.

Last updated September 22nd, 2023 at 03:16 pm Published April 14th, 2015 at 07:27 am