In FlexRule, rule engine is the core component of the framework that executes business rules, logic and decisions. There are several different ways of modeling business logic (i.e. rules, decisions, flows...) which each of them has their own benefits and advantages.b Depends on the type of logic, you may choose to use different models.
Decision table logic
Decision table logic is used to execute Decision table which represents a set of business rules. When the rules structured in a form that they share the same business concept and condition structure then a Decision table is a valid choice. In some scenarios you see the same rule is repeated but with different values and different conditions. For example, discount or tax calculation are a classic case for modeling the logic as a Decision table.
Decision table can be modeled by XML, Spreadsheet or Table editor.
Natural language is a way of encapsulating the complexity of expressions into a high level model that uses your own business domain and spoken language to model them. This allows a high degree of flexible statements to connect to each other and compose a business logic that drives a decision.
Decision Requirement Diagram (DRD)
When there are multiple steps to take a decision which each of them has their own logic (business rules) then you can use Decision model and notation (DMN) to model the decision whole decision. A DMN allows you build a hierarchical high-level decision for a business scenario and then link each node of it into other logic implementation. The other way to look at it is that a DMN allows you to build a graph of decisions which the are connected to each other based on their between dependencies.
Information Requirement Diagram (IRD)
When dealing with data logic, to compose, build information from some other data sources, the Information requirement Diagram or IRD can be useful to model the logic in a graphical way. This model underneath uses monadic operators for execution.
This form of logic can be used to model procedural algorithm. They represent the sequential form in nested hierarchical tree. This logic can be used when complex algorithmic and sequential logic is required. For instance, if the logic needs to
- looping and iterating values
- to access external resources such as database or web services
- or may have sequences of If-Then-Else
This can be a first attempt to extract logic from your code into a logic module that can be shared as an executable model.
When the logic models are executed, they can have Inter-link communication calling the other procedural logic or rules. Or even they can share a piece of an algorithm (Using scopes) with each other (if they are multiple). Writing a procedural logic is very much like a procedural programming and can have parameters. The logic may have some input, local and output parameters that the caller (i.e. application) can pass the inputs through and the model would use those and process them and will store the result into output parameters. Another important feature of this logic is it can communicate back to its host using events to retrieve information for the host.
This type of logic is used when Constraints (also called "action assertions") is going to be validated. This model simplifies and centralizes the validation process of a logic, data or process in a declarative way. It can be used in all layers of the application (Server and client sides). It also provides notifications to give a feedback what has gone wrong if the logic, data or process has not passed the validation logic. The rule logic can be extended using custom commands. Also, it allows to define the rules that receive input parameters.
It uses an XML-based language to define the logic to be validated.
This type of logic has similar behavior to validation, the difference is that it can handle the delayed execution of the consequences. And it maintains the execution in a queue that would handle conflict resolution and can be used to drive goals in decision making.
When complex sequencing of multiple actions is required, flow model is a good option. This logic is usually suitable for fully automated sequence of:
- Operations, actions or tasks
- Rules or decisions
- Data or information
- Or combination of any of the above
The flow logic allows you to combine and orchestrate these and execute them in the defined sequence. The decision to route the execution path can be dynamically taken. The nodes in the flow model can be customized as a code based node or as a node that is linked to a Procedural logic or an expression. In the flow logic also it is possible to suspend the execution by pausing the flow and whenever it is needed continue the execution from the point it was paused. This allows you to manage the state of the flow offline and resume it when required.
A workflow is a sub type of flow logic. This is designed to manage automatically or semi-automatically process. The processes that need an action to be taken from outside the system that is running by an actor. The actor can be either another system or a human. The workflow logic is designed to support:
- Document or entity based workflow
- Collaboration workflow
The workflow logic support out-of-box functionalities to manage:
- Workflow hydration and dehydration
- Workflow timeout and external event receiver nodes
- Workflow state and data persistence store
- Workflow scheduling
- Workflow expired task monitoring
The workflow is designed to accept signals from the external environment and response to the input signals automatically.
All the logic have their own API specification that can be check at here.