◷ Reading Time: 5 minutes
In FlexRule, a logic document is the core component of the solution that represents application or business logic. There are several different logic documents (i.e., rules, decisions, flows, etc.) each of which has a way of representing a model that explains a logic. Depending on the type of logic, you may choose to use different models.
Decision Table
Decision table logic is used to execute the Decision table, which represents a set of business rules. When the rules are structured in a form that is shared with the same business concept and condition structure, then a Decision table is a valid choice. In some scenarios, you may see that the same rule is repeated, but with different values and different conditions. For example, discount or tax calculation are classic cases for modeling the logic as a Decision table.
The Decision Table can be modeled by XML, Spreadsheet or Table editor.
Natural Language
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 these. 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 needed to make a decision, each of which has their own logic (business rules), then you can use Decision model and notation (DMN) to model the whole decision. A DMN allows you to build a hierarchical high-level decision for a business scenario and then link each node of it into other logic implementations. The other way to look at it is that a DMN allows you to build a graph of decisions which are connected to each other based on the dependencies between them.
Information Requirement Diagram (IRD)
When dealing with data logic, to compose and build information from some other data sources, the Information requirement Diagram or IRD can be useful to model the logic in a graphical way. The model below uses monadic operators for execution.
Procedural logic
This form of logic can be used to model procedural algorithms. These represent the sequential form in a nested hierarchical tree. This logic can be used when complex algorithmic and sequential logic is required. For instance, if the logic needs to:
- loop and iterate values
- access external resources, such as database or web services
- has sequences of If-Then-Else
This can act as 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 they can even share a piece of an algorithm (Using scopes) with each other (if they are multiple). Writing procedural logic is very much like procedural programming and can have parameters. The logic may have some input, local and output parameters that the caller (i.e., the application) can pass the inputs through. The model will use and process those and will store the results 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.
Validation logic
This type of logic is used when Constraints (also called “action assertions”) are going to be validated. This model simplifies and centralizes the validation process of logic, data or process in a declarative way. It can be used in all layers of the application (i.e., both server and client sides). It also provides notifications to give feedback as to 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 the definition of rules that receive input parameters.
It uses an XML-based language to define the logic to be validated.
Decision logic
This type of logic has similar behavior to validation, the difference is that it can handle the delayed execution of the consequences. It maintains the execution in a queue that can handle conflict resolution and can be used to drive goals in decision making.
Flow logic
When complex sequencing of multiple actions is required, the flow model is a good option. This logic is usually suitable for a fully automated sequence of:
- Operations, actions or tasks
- Rules or decisions
- Data or information
- A 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 taken dynamically. 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, it is also 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.
Workflow logic
A workflow is a sub-type of flow logic. This is designed to manage a process automatically or semi-automatically. These are the processes that need an action to be taken by an actor from outside the system that is running. The actor can either be another system or a human. The workflow logic is designed to support:
- Document or entity based workflow
- Collaboration workflow
The workflow logic supports 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 respond to the input signals automatically.