Business Rules Engine™ is a powerful engine of configurable rules for insurance companies, banks and other financial institutions can design from simple control flow to complex functions across multiple channels. This platform provides greater operational efficiency and effectiveness, and can be purchased independently or embedded in Insurance Service Bus™.
Each of these rules is defined independently of the processes with which the company operates, allowing if policy changes occur in the company, the processes are automatically updated without changing the classes, but only changing business rules, which can be called from any service or process and define the current parameters in real time.
As shown in the graph below, the dynamics of the solution is synthesized in processes and rules that are analyzed and made thanks to the powerful rules engine of our product Business Rules Engine, which gives the company the desired results and actions.
When an application is designed, it is very important to conceptualize what business logic, since the filing of an application changes with the different technologies, but business rules remain still own the market, so to the extent that it can effect this separation, it will be better positioned to meet the demands market and customer expectations.
One of the possible solutions to achieve this separation as possible involves isolating business logic programming, so that the rules can be understood by all members of the organization, such as sales managers or business.
The rules are divided into two blocks: > Section If : It is considering the condition of the rule. > Section Then: It is the result of actions or rule where the action is executed when the condition is met.
In general terms, it is always desirable that rules and business policies (restrictions) are separated from business processes carried out by the company, in order to change such restrictions without changing explicitly the processes that implement as exemplified by the following graphic:
A case could be the use of a rule that models discounts to a select group of clients during a given period. It could be inferred as follows:
All clients assigned within the “A” category, are from Argentina, who have purchased auto insurance in January 2016, receive a 10% discount on the next purchase of insurance.
Here, instead of implementing a restriction that involves modifications to the code, the business rules that define statements such as “If used & lt; condition & gt; Then & lt; action & gt; “. They correspond to the policies established by the organization, characterized by being declarative and not procedural, added to which are subsequently processed by a rules evaluation engine.
Insurance Core™ architecture combines a focused processes and services designed to scale (SOA) with application integration and service partners approach. The platform supports both modules can be implemented with Open Source tools as container owners, obtaining a high availability environment.
100 % Web, supports multiple devices. It is not necessary to realize discharges to be able to use the system, it is enough to have only the direction URL.
It is service-oriented (SOA), based on REST API. HTTP services can be consumed by a wide range of clients including web browsers, mobile, other systems or tablets.
Each process and resource data is exposed through an HTTP service enabling communication and integration between various current or future devices.
The platform has an extended BPM (BPMN 2.0) with ability to solve RunTime time domain objects (insurance business). These objects can potentially be mapped to the data layer (relational database, partner service, etc).
This extension of the BPM generates an added value that gives simplicity and ease of reading process. Thus the processes have the ability to understand the business model with their corresponding objects in a natural way, avoiding technical actions within the process.
The process layer also has the ability to execute business rules thanks to embedded rules engine.
It maintains business rules, constantly updating.
The data access layer provides a separation of code by its function. This approach provides flexibility to change the data persistence mechanism in the desired time.