Runtime:Introduction

From FlexRule Wiki
Jump to: navigation, search

FlexRule Runtime Technical Document Sections


Introduction

FlexRule is a framework for business rules, decisions, processes, worflows and application logic. It provides sets of libraries and components for software designers and developers to create flexible applications that embrace changes easily, quickly and with little expense. FlexRule has several types of components as an engine. These components deal with logic and rules in such a way that they can be modularized and externalized from the application’s source code and the execution can be delegated to FlexRule.

FlexRule supports the following engines:

  1. Procedural Engine
  2. Inference Engine
  3. Flow Engine
  4. Workflow Engine
  5. Validation Engine
  6. Decision Engine

All of these engines have been designed to be extensible, and you as the software designer or developer are able to extend its functionalities and adapt it to your software solutions easily. Your application can communicate with its logic and rules via the FlexRule framework and delegate their loading and execution to FlexRule.

By separating the rules and logic from the software solution and by modularizing and externalizing them, FlexRule decouples the logic and rules from the application so that they can vary independently. Each part can be changed and extended without knowing about the changes in the other part, having different people responsible for managing each of them. As a result, you will be able to embrace changes into your application quicker, cheaper and easier.

Communication with the FlexRule framework

In addition, FlexRule increases reusability and consequently decreases the cost of your software, which is the ultimate goal of FlexRule’s solutions.

In software design, it’s customary to break down the application responsibilities into modules and layers. This architecture helps reduce the coupling between multiple parts of the application with different responsibilities.

For example, consider an architecture that has three layers: user interface, business, and data access. Using FlexRule helps make this layered architecture as flexible as possible by making the logic and rules interchangeable in the application, which is usually applicable to the business layer or the user interface process controller. Therefore, changing the rules and logic does not require changing the code inside the application, and no compiling is needed.

The changes can be applied in the rule and logic model with little effort from the developer. The changes can be applied by different members of the development team. Even better, when business rules need modification, the changes can be applied by the people in charge of the business themselves.

High-Level Characteristics

All software has features that enumerate the software’s functionalities, but FlexRule’s list of high-level characteristics is different and form the basis of its competitive advantage. You may find these features separately in different products, but not all in one. All of FlexRule’s features have been developed on a set of fundamental design disciplines and best practices that make FlexRule a flexible extension point of your application.

Transparent Loading

Transparent access to rules is one of the features that bring flexibility to your applications. This transparency allows you to store rules in any way you want, and regardless of the storage type and location the application can load the rules by providing an address protocol to the FlexRule framework.

Loading rules and logic via an address


Event-Driven Rules and Logic

Regardless of the type of engine you are using, FlexRule provides an event-driven platform. This feature allows you to have full control from rule execution, which is one of the extensible points of FlexRule. The events can be raised inside the rules and logic model and then handled inside your application.

Rules sending signal to application

One of the most powerful features of this kind of event system is the influence of your application on rule execution. This influence means that you can send data back to the rule execution context and, based on this on-the-fly data, make new decisions or change the rule and logic execution path.

Logic Interlink

Another key feature of FlexRule involves executing rules as a chain.

Executing in chain

The framework has a rule interlink that allows you to load, call, and execute a rule and logic inside another rule and logic and then to return the result to the application in every state of execution you require.

The important point of this chain execution is that the previous rule can send parameters as an input argument to the next rule. Therefore, your application does not need to manage the parameters passing between rule executions.

Language and Communication Model

Another important feature is business language extensibility. FlexRule has a model definition language that is exposed as a programming interface. This feature allows you to create your own language based on the interface by providing a different implementation for it.

Use exiting language or design your won

For example, both S-expression-based and Extensible Markup Language (XML)–based languages (for the procedural engine) are based on this feature. You are not limited to having just these two languages: you can create your own neutral rule language.

Communication with FlexRule can be categorized into these two modes:

  1. Application programming interface (API) mode
  2. Language mode (high level)

In API mode, you as the programmer are responsible for communicating with FlexRule’s object model APIs and for accomplishing your desired task. When you use the language mode, you send only a few commands to the engine, which get executed without direct communication with a different part of the FlexRule framework.

Apart from language and model of communication in FlexRule, you can use some other built-in commands in a rule and logic model—for example, an If-ElseIf-Else command. These rule commands are also extensible, which mean that if you cannot find a command you want, you just create your own and use it as a part of your rule and logic model, just as you use pre-existing commands.