We have recently introduced our first sample application which is a simple travel insurance calculator. Today we shall look at how it works in detail.
In this article, we will provide a detailed explanation of how our travel insurance sample application works. We will begin by giving an overview of the entire web application and its components, and then we will move on to a detailed description of the Rule Flow that controls the calculation process. By the end of this article, you will have a clear understanding of how the application works and how the Rule Flow controls the entire calculation process.
If you don’t know what a demo app is, be sure to check out our previous article: decisionrules.io/articles/decisionrules-in-action.
All available sample applications can be found at samples.decisionrules.io.
Before we dive into the description of the web application, Rule Flow, and the individual rules in DecisionRules, it is important to clarify the process that takes place during the application's runtime, as well as the data that it works with.
In order to fully understand how the entire application works, it is essential to know what data are processed.
The output data is used on the web site for the client as a result of the calculation.
The web application consists of two main pages:
The entire calculation process in DecisionRules is controlled by this Rule Flow, which contains rules of different types (Decision Tables and Scripting Rules). In the image above, you can see the Rule Flow diagram.
Rule Flow diagram description:
Each rule has a specific role in calculating the final insurance price. Whether it is the estimation of the risk factor or the calculation of the final prices of travel packages. The calculation is mainly based on the so-called risk factors, which are numbers between 0 and 1 determining the degree of risk of individual input data. There are several risk factors such as region risk factor, age risk factor, etc. After all of the individual factors are estimated and the number of days spent on the trip is calculated, the values are inserted into a predetermined formula, which calculates the “totalRiskFactor” value that is used to calculate the final package prices. Risk factors are commonly used by the business owners, which can simply estimate the risk factors and simply update the rules with their values, the changes are smooth, without implementation and on click applied.
You may have also noticed that our Rule Flow uses a few scripting rules. When designing these rules, we found it more appropriate and efficient to put some operations into scripting rules. All scripting rules are used for advanced work with data or their modification but, it's important to note that scripting rules are not the only approach available. All of the scripting rules used in this example can be replaced with Decision Tables or other alternatives.
This rule is used to calculate the days spent on the trip. It takes in “departureDate” and “arrivalDate” values as input and outputs the number of days spent on the trip. For this calculation, we used the DATEDIFF() function, which, as the name suggests, calculates the difference between two dates. If you want to find out more information about the DATEDIFF() function, be sure to check out our documentation.
This set of rules is designed to estimate the continentsRiskFactor value for a given array of continents. The input to the rules is an array of continents, and the output is a single value representing the overall risk factor for all the continents inside the input array.
To calculate the continentsRiskFactor value, the "Continents Script" Scripting Rule calls the "Continents" Decision Table to determine the risk factor for each continent in the input array. The results from the Decision Table are then passed back to the Scripting Rule, which adds them into a single overall risk factor.
As an example, consider the following array as an input: ["europe","america"]. In this case, the "Continents Script" Scripting Rule will call the "Continents" Decision Table to determine the individual risk factors for the first continent (“europe”), and the second continent (“america”). The Scripting Rule will then add these risk factor values together to produce an overall risk factor called continentsRiskFactor. In this example, the resulting continentsRiskFactor value would be "0.45".
This Scripting Rule calculates the total risk factor for a set (an array) of continents by calling a Decision Table called "Continents" with the input data (array of selected continents) as the data payload. The Decision Table returns the risk factor for each continent. These values are then mapped and stored in an array called "continentsRiskFactorMapped". The Scripting Rule then uses the reduce() method to add all of the values from "continentsRiskFactorMapped" together to get a single number representing the total risk factor for the selected continents, “totalContinentsRiskFactor”. This number is then rounded to two decimal places to account for decimal rounding in JavaScript's binary floating point numbers. This rounded total risk factor is then set as an output and returned.
It is important to note, that business users do not need to update the script, which is prepared as a box solution, managing the decision table with the whole setup of the risk factors.
This rule is used to assign the values of risk factors for a given set of continents based on the predetermined conditions. It takes in the "continents" array as input and outputs an array of "continentRiskFactor" values. For example, if the input array is ["europe", "america"], the output would be [{"continentRiskFactor": 0.35}, {"continentRiskFactor": 0.1}].
This rule is used to assign the risk factor for a specific travel type based on the predetermined conditions. It takes in the "travelType" value as input and outputs the corresponding "travelTypeRiskFactor" value. For instance, if the input value is "study-visit", the "travelTypeRiskFactor" value will be “0.4”.
This rule is used to assign the risk factor for a specific sports activity based on the predetermined conditions. It takes in the "sportActivities" value as input and outputs the corresponding "sportRiskFactor" value. For instance, if the input value is "risk-sports", the "sportRiskFactor" value will be “0.9”.
This set of rules is designed to estimate the peopleRiskFactor value for a given array of people and their ages. The input to the rules is an array of objects, with the individual ages being the properties of the objects, and the output is a single value representing the overall risk factor for all of the people in the array.
To calculate the peopleRiskFactor value, the "People's Age Script" Scripting Rule calls the "People's Age" Decision Table to determine the risk factor for each person in the input array. The results from the Decision Table are then passed back to the Scripting Rule, which adds them into a single overall risk factor.
As an example, consider the following array as an input: [{"age": 18}, {"age": 26}]. In this case, the "People's Age Script" Scripting Rule will call the "People's Age" Decision Table to determine the individual risk factors for the first person (age: 18) and the second person (age: 26). The Scripting Rule will then add these risk factor values together to produce an overall risk factor called peopleRiskFactor. In this example, the resulting peopleRiskFactor value would be "0.75".
This Scripting Rule calculates the total risk factor for a given array of people based on their ages. It calls a Decision Table called "People's Age" with the input data (i.e. the array of objects, with each person's age being a property of the corresponding object) as the data payload. Due to the structure of the Decision Table “People's Age", the call uses the FIRST_MATCH solving strategy to work as intended. The Decision Table returns the risk factor for each person. These values are then mapped and stored in an array called "peopleRiskFactorsMapped". The Scripting Rule then uses the reduce() method to add all of the values from "peopleRiskFactorsMapped" together to get a single number representing the total risk factor for the selected people (totalAgeRiskFactor). This number is then rounded to two decimal places to account for decimal rounding in JavaScript's binary floating point numbers. This rounded total risk factor is then set as an output and returned.
Again, it is important to note, that business users do not need to update the script, which is prepared as a box solution, because the calculation is driven by the parameters in the decision table.
This rule is used to assign the risk factor for an age group based on the predetermined conditions. It takes in the "age" value as an input and outputs the corresponding "ageRiskFactor" value. For instance, if the input value is "23", the "ageRiskFactor" value will be “0.4”. It is important to note, that due to the structure of this Decision Table, we have to uses the FIRST_MATCH solving strategy, otherwise the rule will output all of, that meet the conditions.
This rule is used to calculate the total risk factor. It takes in all of the calculated risk factors and the number of days spent on the trip as input values and outputs the totalRiskFactor value. The totalRiskFactor is calculated using a placeholder formula in the image above, which can be updated with a more accurate one at any time.
It's worth mentioning that we don't need to use any conditions for this rule in this example. However, Decision Tables generally require at least one condition. Therefore, we need to use a placeholder condition such as "peopleRiskFactor == anything" since it will always evaluate to true.
This set of rules calculates the final package prices based on the totalRiskFactor. The input for these rules is the totalRiskFactor value, and the output is an array of individually calculated package objects that can be easily modified in the Decision Table.
This Scripting Rule is only used for formatting of the return values. It calls a Decision Table called "Packages" with the totalRiskFactor value as the data payload and returns the calculated packages as an output.
This rule is used for the creation, deletion, management, and price calculation of packages. It takes the totalRiskFactor as input and outputs the calculated packages. The package prices are calculated using a placeholder formula in the image above, which can be updated with a more accurate one at any time. The price calculation uses a ROUND() function, which as the name suggests, rounds the number, in this case to two decimal places.
You can easily add more packages by duplicating one of the existing packages and editing its data. Alternatively, you can quickly change the price calculation by modifying the calculation formula. The modification options are virtually limitless.
It's worth mentioning that we don't need to use any conditions for this rule in this example. However, Decision Tables generally require at least one condition. Therefore, we need to use a placeholder condition such as "peopleRiskFactor == anything" since it will always evaluate to true."
In this article, we provided a comprehensive overview of our sample application. We started by exploring the web application, and then we delved into the Rule Flow and its individual rules. We hope that this information has been helpful and that you now have a better understanding of how our sample application works.
If you want to learn more about how DecisionRules can help and benefit your business, be sure to visit our website or LinkedIn page. You can also speak with our experts about your specific use case or the capabilities of DecisionRules. Our sales team is also available to answer any questions you may have, and would be happy to schedule a demo for you to see DecisionRules in action.
Thanks for reading!
