[Progress News] [Progress OpenEdge ABL] Diving Deeper into Composite Applications

  • Thread starter Thread starter Thierry Ciot
  • Start date Start date
Status
Not open for further replies.
T

Thierry Ciot

Guest
In a previous blog, we outlined what composite application characteristics and benefits are. In this blog, we will explore in more detail the example application we touched on in the initial blog and how it was designed and implemented.

Application Design​


Rather than having a monolithic and large decision service, we have designed the application to be composed of multiple independent services. Some of these services are internal (services we author) and some are external (services hosted by a third party).

We use external REST services for real-time metrics to compute a quote that is as current as possible (for example, we want to get the current price of electricity for a specific location).

Implementation​


We used a no-code business rules system for authoring the business logic as decision services. Business users can use such a tool to directly create and maintain the business logic without involving additional programmers.

We deployed these services in AWS step functions. The step functions are coordinating the execution of the various decision services and calling two different REST services.

The step functions and the decision services are completely serverless and automatically scale up or down according to usage. As a result, the solution doesn’t require managing instances or running load balancers and other artifacts of highly available and scalable applications.

Application Overview​


The application goes through the following workflow:

Workflow



In this diagram, all services prefixed with DS_ are internally developed while the ones prefixed with Rest_ are external services.

The workflow is initiated with the data entered by the user on the website. Then various steps compute additional data to make an offer to the user.

Here, we have decomposed the problem into multiple independent decision services, like computing a rebate, the savings the user would have over the years, the price quote and the loan offers.

The second step shows a parallel step where two tasks are happening at the same time and independently of one another. On the left side, we compute the rebates using an internal decision service while on the right side, we call a REST service to get the current price of electricity for a specific location. The goal is to use the time it takes to get the REST data to do some computations.

How Internal Services Are Developed​


Internal services are developed in the Progress Corticon.js no-code business logic development tool. This tool provides a simple yet powerful interface to express business logic using a spreadsheet model. This is very powerful as it allows business analysts to develop, maintain and test business logic without having to involve programmers.

A picture is worth a thousand words, so here is an example decision service in the Corticon.js tool:

example decision service in the Corticon.js tool with multiple columns and rows capturing conditions and actions



In this decision service above, we compute a rebate that is composed of two elements: a flat rebate value and a percentage to be applied to the overall installation cost based on various conditions like state of residence and type of installation. The logic is expressed as a set of conditions and a set of corresponding actions when the conditions are met.

Each column is a rule. For example, in the first rule (column 1), the business analyst expressed multiple conditions: when the state is MA, the type is residential and the installation cost is less than $10k, then the rebate is $1k (Row E of Actions panel). The second rule (column 2) is similar; when the installation cost is greater than $10k, then the flat rebate is worth 14% of the installation cost (row D) and the applicant receives an additional 5% (row C).

You can see how succinct this is compared to what would otherwise be hundreds of lines of code. No complex or nested “if” statements that are hard to read and maintain. No “for loop” to process multiple entries. It is easily readable given the number of conditions and actions to take. This makes the business logic very easy to maintain and a business analyst can update the rules without having to communicate changes to an IT department. This results in tremendous productivity gains.

The platform also provides multiple no-code tools in the form of logical loop analysis, rule completeness and conflict analysis. To learn more about the value and productivity gains of these tools, read our blog, “Getting Your Business Logic Right at Low Cost.”

Conclusion​


It is quite remarkable that thanks to serverless technologies and no-code systems like the Corticon.js business rules engine, a very small team can develop, test and deploy such an application in just a few days of work. Historically, this would take many weeks or months, and it would have required engineers with many different skillsets to work on the project.

Additionally, the application scales very well, is elastic, does not require maintaining any server hardware in the traditional sense. Best of all, it costs nothing when not in use.

To sign up for a trial or demo of the Corticon platform, visit our Getting Started page.

Continue reading...
 
Status
Not open for further replies.
Back
Top