Nowadays it’s not enough for decision-making applications to simply execute a complex rules-based transaction, forget about it, and wait for the next one. These applications frequently have to maintain states of the business objects they manage and and based on their states invoke different decision services. Orchestration of the decision services becomes a serious issue but different implementation techniques frequently utilize State machines. In this post we will use the DMCommunity Aug-2019 Challenge to demonstrate how it can be done.

The Challenge “Dynamic Loan Approval” is an example of perpetually running decision-making applications which should be able to learn from already executed transactions and evaluate new facts as they become available. I plan to make a presentation “Creating Intelligent Perpetually Running Applications with Business Rules” at BBC-2019 later this year.

This challenge deals with the following loan approval scenario as new facts become known as the bank analyzes different facts related to the loan application:

This video demonstrates a possible implementation with a decision engine integrated into a PUB/SUB architecture. We may implement such application using different tools such as:

• Enterprise Service Bus with a PUB/Sub Message Broker and Time Manager
• Apache Kafka
• AWS Lambda functions integrated with event handling mechanism provided by AWS Steps Functions
• any other combination of tools.

Independently of how we implement such an application, at the heart of it will always be a Finite State Machine (FSM) that controls what should be done when new events are coming while the loan is being in different states, e.g.

• Run a rule engine (or a decision service) to evaluate load status (Approved, Declined)
• Change Loan State (New, Waiting for Related Facts, Completed, Finalized)
• Produce new events (Investigate Related Facts, Loan Analysis Completed)

State Machines are a very powerful while intuitive mechanism for state management. But in reality, a state machine can be considered as a special case of a typical DMN-like decision table. For example, here is an example of the state machine that can control the logic of the above application:

Let’s consider how it works supporting the loan approval logic that a bank’s business analysts may establish and easily change without any help from IT. The first two conditional columns describe different combinations of Loan State and Incoming Events, and the for action-columns describe what should be done for each combination. Let’s go through this state machine row-by-row.

Rule 1. If the Loan State is New and we received the event New Loan Request, first we should analyze the loan to determine its new status (Approved/Declined) by executing the decision service “DetermineLoanStatus” – as you can see actually all rules will execute this service (so we merge all rows in the column “ActionExecute”. Then we will transform the loan into the state “Waiting for Related Facts”, set Waiting Period to 3 days, and will produce a new Outgoing Event “Investigate Related Facts”.

Rule 2. If the Loan State is Waiting for Related Facts and we received the event Loan Request Modified, we again should call the decision service “DetermineLoanStatus”, leave the loan in the state “Waiting for Related Facts”, set Waiting Period to 7 days, and again produce a new Outgoing Event “Investigate Related Facts”.

Rule 3. If the Loan State is Waiting for Related Facts and we received the event New Related Fact, we again should call the decision service “DetermineLoanStatus” that is supposed to take into consideration the new fact while evaluating the Loan Status, leave the loan in the state “Waiting for Related Facts”, set Waiting Period to 7 days, and again produce a new Outgoing Event “Investigate Related Facts”.

Rule 4. If the Loan State is Waiting for Related Facts and we received the event Related Fact Modified, we again should call the decision service “DetermineLoanStatus” that is supposed to take into consideration the modified fact while evaluating the Loan Status, leave the loan in the state “Waiting for Related Facts”, set Waiting Period to 5 days, and again produce a new Outgoing Event “Investigate Related Facts”.

Rule 5. This rule will handle situations when the Loan State is Waiting for Related Facts and the Waiting Period Expired, the fact that probably was automatically generated by an embedded Time Manager. In this case, we again should re-run the decision service “DetermineLoanStatus”, transform the loan in the state “Completed“, set Waiting Period to 0 days, and again produce a new Outgoing Event “Loan Analysis Completed”.

Rule 6. This rule will be triggered by the event Finalize that probably will be created by a bank manager after receiving the message from the Rule 5 “Loan Analysis Completed”. In this case, we again should re-run the decision service “DetermineLoanStatus”, transform the loan in the state “Finalized“, set Waiting Period to 0 days, and produce a new Outgoing Event “Loan Analysis Finalized”. After this event probably the application will send an email to a borrower with Loan Status (Approved/Declined) and possible explanations produced by our decision service  “DetermineLoanStatus”. The finalized loan probably will be archived in the state “Finalized”.

Rule 7 is needed to handle the situations when a borrower decides to change the loan request (the event “Loan Request Modified”) after it was finalized, e.g. loan amount or loan term were modified. Then the same state machine will continue to manage the loan approval process using the same rules.

With this state machine it’s very simple for a business analyst to modify the number of days between different events or add new events and states. In general state machines similar to the described one are oriented to business people allowing them to describe how to handle different business situations within their complex business processes over time.

You may find a possible implementation of the decision service “DetermineLoanStatus” and all related rules that support the above scenario in the standard OpenRules installation – see the project “LoanDebtsAndEquities”.  Here are the main components:

See also this presentation.