T
Thierry Ciot
Guest
Progress MarkLogic is a robust and reliable enterprise database, especially as a single integrated backend for multiple data models.
Whether you need to run business logic on one or multiple data models, creating, testing and maintaining business logic is always a difficult task. There are many reasons why this is the case. Some of the reasons we hear most often are:
In this blog, we’ll explore how Progress Corticon.js solves this problem and transforms the development of business logic for complex rules. The transformation lies in how rules are directly developed, tested and maintained by business specialists who do not need to be programmers. In other words, the rules are owned by the business group itself. When using Corticon.js, business logic becomes real services, and the role of the integrator is to use these services as efficiently as possible.
This blog is for architects and application designers working with MarkLogic databases and associated system applications. It shows how, as a decision-maker, you can greatly improve how business logic is developed, tested and deployed. It is also useful for integrators of such systems as they get an understanding of how a no-code decision service can be integrated into the MarkLogic processing pipeline.
We will explore how business specialists provide these decision services with a simple car insurance example. The insurer is charging a user on daily usage. Specifically, the use case is to compute how much to charge the user based on distance driven today, risk level of zones driven and vehicle cost.
In Corticon, business analysts work with two main artifacts to create a decision service, rulesheets and ruleflows. Additionally, Corticon provides testing at the decision service level (system testing) or the rulesheet level (unit testing).
In the rulesheet, the analysts express the rules conditions and associated action. In the ruleflow, they express how all rulesheets are connected to create a decision service.
In this simple example, we see how a decision service is decomposed into three independent rule sets (three Corticon rulesheets). There are many advantages to such a decomposition. For one, this allows for scaling as each business analyst can work on their specific domain independently.
Additionally, the ruleflow—as its name indicates—specifies the order of execution.
Additional constructs are available to modelers. Of course, a ruleflow can specify different branches to execute depending on business data. For more complex projects, a ruleflow can be decomposed into subflows for better organization and scalability.
The core of the business rules is written in a familiar spreadsheet like the interface shown in the following image.
For example, rule 2 specifies that a driver, aged 18 to 25 with 2 years of driving experience, has driven today a distance in the range of 1 to 29. All that sums up the cost to be 3.98. Additionally, for all cases (column 0), the business analyst records the computation date and computes the driver’s age.
One key aspect of enabling business specialists to author business rules is to provide a common understanding of the data available for processing as input and output.
Corticon provides a view of the enterprise data in an easy-to-work way for the business specialist. If needed, it provides an optional mapping between the actual data and the business representation. This allows business users to work with names or terms that are more familiar to them without impacting the integration of the decision service into the rest of the application.
Typically, as an architect or application designer, you may have to provide this vocabulary to the business specialists.
Here is an example view:
Note that this is an oversimplified vocabulary for illustrating concepts. In practice, Corticon supports very complex vocabulary with very deep relationships (1 to 1, 1 to n or many to many). It is common for us to see a vocabulary containing thousands of items; that’s why we have a filter capability that allows the user to narrow complex vocabulary down to area of interest.
As you have seen in the example, business specialists focus on the business rules in a technology-agnostic fashion. That is, they do not have to be trained or even understand the programming language(s) of the solution with which the decision services integrate.
To provide an integration point, Corticon allows the business rules to be exported to specific target platforms. Corticon supports Java, .Net and JavaScript.
The export process is typically done within a CI/CD pipeline but can also be done interactively with Progress Corticon Studio. Here is an example of a Corticon dialog for packaging the rules for execution:
The decision service “Calculate Daily Insurance” is exported for integration with MarkLogic and could also be exported to various serverless cloud functions or even exported to run directly in a browser. Corticon provides a lot of architectural choices to future-proof your solution.
When exporting to MarkLogic, you will get a decision service that can run directly in MarkLogic as server-side JavaScript providing high performance and simplicity of deployments.
Using a no-code solution for developing some of your MarkLogic business logic provides tremendous value:
In a future blog, we will explore two design patterns for decision services in MarkLogic server-side JavaScript. Stay tuned.
If you want to know more and get a demo of what we covered in this blog, feel free to register for the MarkLogic Community Event April Edition. You can also enroll in a free training for Corticon.js.
LEARN MORE ABOUT CORTICON
Continue reading...
Whether you need to run business logic on one or multiple data models, creating, testing and maintaining business logic is always a difficult task. There are many reasons why this is the case. Some of the reasons we hear most often are:
- Business rules are very complex.
- There are not enough programmers to take on development and maintenance.
- Turnover adds to the headache as knowledge of existing coded logic quickly fades.
- Change requests from the business side are coming faster than before and they must be implemented within a very short turnaround time.
- Miscommunications between the business side and the implementation side result in incorrect, incomplete and buggy implementations.
In this blog, we’ll explore how Progress Corticon.js solves this problem and transforms the development of business logic for complex rules. The transformation lies in how rules are directly developed, tested and maintained by business specialists who do not need to be programmers. In other words, the rules are owned by the business group itself. When using Corticon.js, business logic becomes real services, and the role of the integrator is to use these services as efficiently as possible.
Who Is This Blog For?
This blog is for architects and application designers working with MarkLogic databases and associated system applications. It shows how, as a decision-maker, you can greatly improve how business logic is developed, tested and deployed. It is also useful for integrators of such systems as they get an understanding of how a no-code decision service can be integrated into the MarkLogic processing pipeline.
Exploring Via an Example
We will explore how business specialists provide these decision services with a simple car insurance example. The insurer is charging a user on daily usage. Specifically, the use case is to compute how much to charge the user based on distance driven today, risk level of zones driven and vehicle cost.
In Corticon, business analysts work with two main artifacts to create a decision service, rulesheets and ruleflows. Additionally, Corticon provides testing at the decision service level (system testing) or the rulesheet level (unit testing).
In the rulesheet, the analysts express the rules conditions and associated action. In the ruleflow, they express how all rulesheets are connected to create a decision service.
Example Ruleflow
In this simple example, we see how a decision service is decomposed into three independent rule sets (three Corticon rulesheets). There are many advantages to such a decomposition. For one, this allows for scaling as each business analyst can work on their specific domain independently.
Additionally, the ruleflow—as its name indicates—specifies the order of execution.
Additional constructs are available to modelers. Of course, a ruleflow can specify different branches to execute depending on business data. For more complex projects, a ruleflow can be decomposed into subflows for better organization and scalability.
Example Rulesheet
The core of the business rules is written in a familiar spreadsheet like the interface shown in the following image.
For example, rule 2 specifies that a driver, aged 18 to 25 with 2 years of driving experience, has driven today a distance in the range of 1 to 29. All that sums up the cost to be 3.98. Additionally, for all cases (column 0), the business analyst records the computation date and computes the driver’s age.
Vocabulary
One key aspect of enabling business specialists to author business rules is to provide a common understanding of the data available for processing as input and output.
Corticon provides a view of the enterprise data in an easy-to-work way for the business specialist. If needed, it provides an optional mapping between the actual data and the business representation. This allows business users to work with names or terms that are more familiar to them without impacting the integration of the decision service into the rest of the application.
Typically, as an architect or application designer, you may have to provide this vocabulary to the business specialists.
Here is an example view:
Note that this is an oversimplified vocabulary for illustrating concepts. In practice, Corticon supports very complex vocabulary with very deep relationships (1 to 1, 1 to n or many to many). It is common for us to see a vocabulary containing thousands of items; that’s why we have a filter capability that allows the user to narrow complex vocabulary down to area of interest.
Deployment
As you have seen in the example, business specialists focus on the business rules in a technology-agnostic fashion. That is, they do not have to be trained or even understand the programming language(s) of the solution with which the decision services integrate.
To provide an integration point, Corticon allows the business rules to be exported to specific target platforms. Corticon supports Java, .Net and JavaScript.
The export process is typically done within a CI/CD pipeline but can also be done interactively with Progress Corticon Studio. Here is an example of a Corticon dialog for packaging the rules for execution:
The decision service “Calculate Daily Insurance” is exported for integration with MarkLogic and could also be exported to various serverless cloud functions or even exported to run directly in a browser. Corticon provides a lot of architectural choices to future-proof your solution.
When exporting to MarkLogic, you will get a decision service that can run directly in MarkLogic as server-side JavaScript providing high performance and simplicity of deployments.
Conclusion
Using a no-code solution for developing some of your MarkLogic business logic provides tremendous value:
- The business rules processing is decoupled from any of the other processing types. From a system architecture point of view, the rules are a service with a clear demarking line.
- You can empower business specialists to author and maintain business rules. Customers report that they get up to 90% gains in developing and deploying business logic.
- You will gain agility as the same business user will be able to adjust the rules very quickly as the business evolves without the costly and time-consuming round trips that are typical between business users and programmers.
- You can free up your precious programming resources and focus on the core aspects of the solution.
- You gain more agility and productivity because the business rules can be developed in parallel to the rest of the system. And they can be tested by a business specialist, independently of the rest of the system.
- Rules can be verified directly by business specialists: Corticon provides logical analysis so the business logic is complete and without conflicts. For more on this topic, read our blog, Getting Your Business Logic Right at Low Cost.
- The rules are documented. As the rules are expressed more as a natural language than coding, the business logic is documented. Too often, business logic documentation is just in the head of programmers and when the solution ages, that knowledge starts to fade or at times is completely lost due to turnover.
- You gain even more agility because the business user does not need to be trained in any of the technologies involved in your application stack. Therefore, you can get started faster and without additional costs.
- Future proofing your business logic: Corticon.js provides flexibility in how you can deploy the decision services: from being embedded within a MarkLogic server to remote services running in any cloud (GCP, AWS and Azure). Direct deployment is also possible in frontend applications like browsers or mobile apps. You can read more on this in our blog, Choices When Architecting and Designing Decision Services.
In a future blog, we will explore two design patterns for decision services in MarkLogic server-side JavaScript. Stay tuned.
If you want to know more and get a demo of what we covered in this blog, feel free to register for the MarkLogic Community Event April Edition. You can also enroll in a free training for Corticon.js.
LEARN MORE ABOUT CORTICON
Continue reading...