◷ Reading Time: 5 minutes
Runtime (FlexRule SDK)
FlexRule Runtime is a framework for business rules, decisions, processes, workflows, and application logic. It provides sets of libraries and components for software designers and developers to create flexible applications that embrace changes easily and quickly. FlexRule Runtime has several types of components for loading models and executing them. These components allow the application logic to be modularized and externalized from the codebase and the execution will be delegated to FlexRule Runtime.
FlexRule Runtime supports the many different types of logic:
- Procedural
- Inference
- Flow
- Workflow
- Validation
- Decision Table
- Natural Language
- Decision Requirement Diagram
- Information Requirement Diagram
- Fact Concept
- Boxed Expressions
…and more…
All of this logic has 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 these logic and via the FlexRule Runtime and delegate their loading and execution to FlexRule Runtime.
Why?
By separating the rules and logic from the code and by modularizing and externalizing them, FlexRule Runtime decouples the logic and rules from the application so they can be changed and updated independently. Each part can be changed and extended without knowing about the changes in the other part, and consequently allows having different people responsible for managing each of them. As a result, the solution will be able to embrace changes quicker and easier with minimum impact.
In addition, FlexRule Runtime increases reusability and consequently decreases the cost of software development, which is the ultimate goal of the FlexRule platform.
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 service
- data access
Using FlexRule Runtime makes this architecture as flexible as possible by enabling the logic and rules interchangeable in the application, which is usually applied to the business layer or the user interface process controller. Also, changing the rules and logic does not require changing the application’s codebase, and no compilation is needed.
Required changes can be applied in the rule and logic model with little effort from the developer. They can be applied by different members of the development team. Even better, when business rules and logic need modification, they can be done by the people in charge of the business themselves.
High-Level Characteristics
All frameworks have features that enumerate their functionalities, but the FlexRule Runtime list of high-level characteristics is a set of principles that we built FlexRule Runtime having in mind.
Transparent Loading
Allowing to store logic documents anywhere. i.e. Cloud, Database, File System, Embedded into assembly and etc.
The application simply accesses the source of the logic documents and provides them to FlexRule Runtime.
Event-Driven Rules and Logic
Regardless of the type of logic, FlexRule Runtime provides an event-driven platform. This allows you to have full control of rule execution. The events are raised inside the rules and logic model and they will be captured and handled by the application.
Logic Interlink
This allows building highly reusable and extensible business logic by chaining existing rules and logic as the building block of the new business logic.
FlexRule Runtime enables logic interlink that allows loading, calling, and executing of rules and logic inside logic document logic document. Once executed, the results are sent back to the application.
Inter-related (linked) logic documents can share values and data. They also can pass parameters in and out.
Intermediate Language
FlexRule Runtime has an executable intermediate language. That means all the high-level models will be defined in this language that Runtime understands and runs them.
This intermediate language is free form and can be modeled in XML, JSON, YAML, S-EXPRESSION, or any other forms of representation.
At the current version of FlexRule Runtime has the XML representation of the language. But this does not stop you to implement the other forms using our guidelines.