KR101981201B1 - Method for implement business rule in insurance company server and system thereof - Google Patents

Abstract

An embodiment of the present invention relates to a method for implementing a lightweight rule engine which comprises: a first data selection step of enabling a first system to select first format data for a business rule in data stored in the first system on the basis of a predetermined condition; a second source data processing step of converting the selected first format data into second format source data capable of constructing second format data through compiling and linking and transmitting the converted second format source data to a second system; a processing engine calling step of enabling the second system to receive the converted second format source data and calling an embedded rule engine capable of compiling and linking the second format source data; and a second data calculating step of enabling the second system to calculate the second format data for the business rule from the second format source data through the called embedded rule engine. According to present invention, work efficiency is greatly increased and maintenance costs can be reduced.

Description

[0001] The present invention relates to a method for implementing a business rule in an insurance agent dealer server and a system for implementing the method,

The present invention relates to a method for implementing a business rule in an insurance agent dealer server and a system for implementing the method. More specifically, a business rule management system built in a central computer system of an insurance company or a bank includes various business A rule is stored and a method for implementing a business rule in an agency server of an insurance company or a bank that provides a service based on an application built on a basis of a part of the business rule and a system for implementing the method.

Every company has guidelines to effectively control the decisions that are required to do business. As an example, a business policy means that the above guidelines are expressed in a sentence and documented, and a business rule (business rule) is defined as a specific condition, an environment, a behavior And so on.

In particular, in the case of a bank or an insurance company that sells atypical characteristic service products that can not be detected by five senses such as sight or tactile sense among various companies, the business rule itself becomes a big factor in determining the characteristics of each service product, The role of the rule developer who professionally develops and regulates rules is of great importance.

In addition to the regulations and compliance requirements of global competition such as borderless competition, government and non-governmental organizations, and internationalization organizations, increasing demand for customer service upgrades and changes in business policies due to IT development demand rapid changes in business rules have. Therefore, systems that manage business rules should reflect these changes quickly, but existing in-house applications or business process management (BPM) alone can not accommodate these changes quickly and effectively.

It is difficult for the conventional system to quickly accept the above-mentioned periodical change because the business rule exists only in a hard-coded form in the application by a conventionally known programming method, so that the rule developer can develop a new rule, Regardless of whether you were trying to modify the rules, you had to negotiate with an IT professional, and you had to code and test independently to implement the rules in your business system within the IT department.

As described above, when a rule developer and an IT delegate go through complicated communication procedures, a lot of time and money are consumed and inefficient, so that a rule developer can implement necessary business rules directly in the business system, It is known that a business rule management system that enables the rule developer to operate and maintain the implemented business rule is needed. Recently, it is known that the low level business rule management system is utilized and utilized in the insurance company or the bank.

Further, if a business rule management system is provided, a product information management system that operates in conjunction with the business rule management system is needed. If the business rule management system manages business rules, the product information management system stores and manages detailed information about the service goods and the goods sold to the customer.

For example, when an insurance company establishes and operates a central server including a business rule management system and a product information management system, the product information management system stores a name of a plurality of service products sold by the insurance company, a validity start date, Etc. are stored as product information. When an insurance agent delivers a request to a dealer server to calculate insurance premiums for a specific customer through the terminal, the agency that operates the application based on the information stored in the central server The server performs functions to allow the insurance planner to check the insurance premiums finally calculated according to the product information and the insurance premium calculation logic provided by the business rule management system.

On the other hand, the insurance market in Japan is built by dealers who sell various insurance products together. Unlike in Korea, Japanese dealers generally use a Windows-based independent business system that does not use a network to sell insurance products. In this process, each insurer establishes business rule and insurance commodity-related information related to its insurance products in a central computerized system, and then performs duplicate work in developing and distributing to dealer's business system. In this process, only a part of the information stored in the central computer system is selected and hard-coded to produce and distribute an application for each agent server. This is inefficient because the application developer has to perform redundant tasks However, there is a disadvantage in that it is troublesome to create an application dedicated to a dealer server every time various information stored in the central computer system is updated, which causes an excessive maintenance cost.

Korean Patent Publication No. 10-2016-0103842 (published on September 26, 2016)

SUMMARY OF THE INVENTION The present invention has been made in view of the above problems, and it is an object of the present invention to provide a business rule management system and a product information management system, In order to provide a method for efficient recycling in the environment.

According to another aspect of the present invention, there is provided a method for managing a business rule in a first system, the method comprising: A first data selection step of selecting the first data; Converting the selected first type data into second type source data capable of building second type data through compiling and linking; A processing engine calling step of the second system receiving the converted second type source data and calling an embedded rule engine capable of compiling and linking the second type source data; And a second data calculation step in which the second system calculates second type data for the business rule from the second type source data through the called embedded engine.

According to another aspect of the present invention, there is provided a system for implementing a business rule in an insurance agent's server, the system including a first system and a second system, A first data selection unit that selects first type data for a business rule from among data stored in the first rule based on a preset condition; Second source data for converting the selected first type data into second type source data capable of building second type data through compiling and linking; A processing engine calling unit for receiving the converted second type source data and calling an embedded rule engine capable of compiling and linking the second type source data; And a second data calculation unit for performing second type data on the business rule from the second type source data through the called embedded engine.

Other aspects, features, and advantages will become apparent from the following drawings, claims, and detailed description of the invention.

According to the present invention, it is possible to easily implement a rule service application operating in an agency server operated on the basis of information stored in a business rule management system and a system of a goods system building a goods information system, The efficiency of the work is remarkably increased and the maintenance cost is reduced.

FIG. 1 is a diagram illustrating a process of operating a conventional insurance business system.
2 is a diagrammatic representation of an overall system according to the present invention.
Figure 3 is a block diagram of an example of a system for generating a lightweight rule engine in accordance with the present invention.
4 is a block diagram of another example of a system for generating a lightweight rule engine according to the present invention.
5 is a diagram for further illustrating the second format data.
6 is a flowchart of an example of a method of providing reference information of a service product according to the present invention.

BRIEF DESCRIPTION OF THE DRAWINGS The present invention is capable of various modifications and various embodiments, and specific embodiments are illustrated in the drawings and described in detail in the detailed description. The effects and features of the present invention and methods of achieving them will be apparent with reference to the embodiments described in detail below with reference to the drawings. The present invention may, however, be embodied in many different forms and should not be construed as limited to the embodiments set forth herein.

Hereinafter, exemplary embodiments of the present invention will be described in detail with reference to the accompanying drawings, wherein like reference numerals refer to like or corresponding components throughout the drawings, and a duplicate description thereof will be omitted .

In the following embodiments, the terms first, second, and the like are used for the purpose of distinguishing one element from another element, not the limitative meaning.

In the following examples, the singular forms "a", "an" and "the" include plural referents unless the context clearly dictates otherwise.

In the following embodiments, terms such as inclusive or possessed mean that a feature or element described in the specification is present, and does not exclude the possibility that one or more other features or components are added in advance.

If certain embodiments are otherwise feasible, the particular process sequence may be performed differently from the sequence described. For example, two processes that are described in succession may be performed substantially concurrently, and may be performed in the reverse order of the order described.

FIG. 1 is a diagram illustrating a process of operating a conventional insurance business system.

The insurer has established and operates an insurer business system that includes a business rule management system and a product information management system. Here, the business rule management system means a system for storing and managing business rules added, deleted and modified by business rule developers. The dedicated application installed in the insurance company business system operates in conjunction with the business rule management system, receives requests from a plurality of insurance planners' PCs, and processes the insurance premium calculation business or the acquisition examination business.

At this time, since the insurance agent PC does not have a rule engine for calculating the insurance premiums or receiving acceptance screening for inspecting whether the customer is eligible for insurance, the insurer's business system and insurance If the network is disconnected from the designer PC, the insurance agent PC can not perform the rule service. Hereinafter, the rule service is collectively referred to as all services that receive the customer's personal information and calculate the result data (the result of the argument examination or the premium calculation result) through a predetermined rule.

As another example of the above-described insurance company business system, there is an insurance company business system in which a rule developer stores goods information and business rules without directly communicating with the insurance agent PC. In particular, Japanese insurers have established an insurance company business system, distributed distributor-specific applications built on the information of the insurer's business system to various dealers, and sell insurance products through agency servers driven by the distributor-specific applications And provide basic services to customers.

2 is a diagrammatic representation of an overall system according to the present invention.

2, the entire system 20 includes a central computer system 210, a developer terminal 215, a dealer server 220, a plurality of insurance agent terminals 230a, 230b, and 230c, It can be seen that it operates in a communication manner. 2 is characterized in that a communication network is not established between the central computer system 210 and the dealer server 220 according to a model used by an insurance company in Japan.

First, in FIG. 2, the central computerized system 210 refers to an insurance company business system including a business rule management system and a product information management system, as described in FIG. A dedicated application installed only in the central system 210 is installed in the central computer system 210 to control the entire operation of the central computer system 210. Various data (product information and business rules) stored in the central computer system 210 It is processed through a Java (JAVA) based engine.

The developer terminal 215 is a terminal that can communicate with the central computerized system 210 and is a terminal used by an application developer. The developer terminal 215 receives the source code data from the central computerized system 210, compiles and links the source code data through the built-in embedded rule engine, and generates a dynamic link library to provide it to the agency server 220. The developer terminal 215 establishes the central computerized system 210 and the intranet 200

The agent server 220 is a device installed in the agent, and performs various functions for sales of the agent while communicating with a plurality of insurance agent terminals 230a, 230b, and 230c. As an example, the agency server 220 may receive the customer's personal information from the insurance agent terminal, process the insurance premium calculation or the argument review for the customer, and return the result to the insurance agent terminal have. The agent server 220 may be plural. Since the number of the dealer servers 220 can be plural, a method for preventing the technical support requirement from occurring in the central computerized system 210 as much as possible is required. The configuration for driving the agent server for the rule service and calling the service through the network increases the complexity of the entire system 20. [ The agent server 220 is provided with an application required to provide a rule service to a plurality of insurance agent terminals.

The agent server 220 is provided with an application for performing an acceptance examination or insurance premium calculation, but the logic that finely constitutes the rules and rules for finally performing an acceptance examination or a premium calculation is a central computerized system 210, and an application installed in the agent server 220 performs a function of simply applying a received rule or logic. 1, when the product information or the business rule on the central computerized system 210 is changed, an application reflecting the changed point is developed by the application developer in a hard-coding form and installed in the agency server 220 I can not help it.

That is, since the applications installed in the central computerized system 210 and the agent server 220 are different applications, the application developer primarily develops an application for operating the central computerized system 210, It is necessary to perform a duplicate operation. If the number of agents is increased and the work performed by each agent is different, it is only necessary to develop an application specialized for each agent server 220 of each agent There is an excessive problem of maintenance cost. The present invention provides a method for solving such a problem, and a detailed method for this will be described later.

The plurality of insurance agent terminals 230a, 230b, and 230c are used by a user other than the rule developer to access the agent server 220 through the communication network 250. Only three insurance agent terminals 230 are shown in FIG. 2, , The number of terminals may be larger or smaller than three.

For example, when the insurance agent inputs the personal information of the customer to check how much the insurance premium of the customer is through the terminal, the agent server 220 receives the personal information of the customer as input data, And calculates the premium according to the logic of the customer's personal information and the rule, and transmits the calculated premium to the terminal of the insurance planner. That is, the insurance agent can be regarded as an end user who uses the business rule that has already been designed, and is different from the rule developer who develops the business rule.

The communication networks 240 and 250 function to connect the central computerized system 210, the agency server 220 and the insurance agent terminals 230a, 230b and 230c and can exchange various wired and wireless communication networks such as a data network, . Particularly, the communication network 240 between the central computerized system 210 and the agent server 220 is referred to as a second communication network 250 between the first communication network, the agency server 220 and the insurance agent terminals 230a, 230b and 230c Even if the first communication network is disconnected and communication between the central computer system 210 and the agent server 220 is impossible, the agent server 220 can continue to provide the rule service to the insurance agent terminals according to the present invention .

Figure 3 is a block diagram of an example of a system for generating a lightweight rule engine in accordance with the present invention.

3, the system 300 for implementing a business rule includes a core system server environment 310, a developer environment 330, and an offline environment 350. [ The system 300 for implementing the business rules of FIG. 3 may be understood as another example of the overall system 20 illustrated in FIG. 2, and for convenience of description, the following description will be made with reference to FIG. 2 .

First, the core system server environment 310 is an environment included in the central computerized system 210 and configured to manage business rules and product information. Here, management of a business rule is collectively referred to as adding, deleting, or changing a business rule and storing an added or changed rule. The management of the product information is collectively referred to as adding, deleting, changing the product information, and storing the added or changed product information. The core system server environment 310 includes a rule server 311, a rule product information storage unit 313, and a task information storage unit 315.

The rule server 311 performs a function of adding, deleting, or changing business rules of service products sold by an insurance company or a bank.

The rule product information storage unit 313 stores a rule added or changed by the rule server 311. [ The rule product information storage unit 313 stores rules to be managed in the time base system, and not only rules to be used in the offline application 338 such as a rule for calculating a premium, a rule for performing an argument review, Various rules are stored.

The rule product information storage unit 313 stores product information of a service product sold by an insurance company or a bank in addition to the above-mentioned rules. The rule product information storage unit 313 receives an instruction from the rule server 311, and can add, delete, or change product information. In the rule product information storage unit 313, not only the data of the product currently sold but also the data of the product whose sale has ended or the data of the product whose sale has not been started yet are stored.

The business information storage unit 315 stores basic information necessary for a task of providing a rule service in addition to a rule and product information. As an example of the task information stored in the task information storage unit 315, information such as the insurance rate is stored in the task information storage unit 315.

The developer environment 330 includes an ERICA source generator 331, a rule source file 332, a visual C ++ project file 333, an ERICA rule server library 332, A business information file 335, a rule dynamic link library 336, a database engine 337,

The ERICA source generator 331 selects a part of the rule stored in the rule product information storage unit 313 and converts it into a rule source file 332. [ Also, the ERICA source generator 331 selects a part of the goods information stored in the rule product information storage unit 313 and converts it into a part of the business information file 335. [ Here, ERICA is regarded as an abbreviation of Embedded Rule Interface for C / C ++ Applications. In addition, since the concrete method of converting the rules into source codes for different programming languages by the ERICA source generator 331 is based on a well-known method, the description of the method will be omitted herein.

As an alternative embodiment, the ERICA source generator 331 may construct a table rule based on a preset row, and generate a rule source file 332 based on the table rule. In general, if you convert a table rule consisting of very many conditions and results to an if-then-else statement, there is a high probability that a resource shortage error will occur during the C ++ compilation optimization process. Thus, the ERICA source generator 331 constructs a table rule first before converting a rule converted into a rule source file 332, and sets the row of the table rule so that it does not exceed a maximum of 200 rows. It is possible to minimize the resource shortage error that may occur in the process.

The rule source file 332 is C ++ source code converted from the rule by the ERICA source generator 331. In this process, the ERICA source generator 331 transforms one rule into one source file and converts it so that the readability of the code can be improved and the management advantage can be obtained.

The visual C ++ project file 333 is a project file for generating the rule dynamic link library 336. [ The visual C ++ project file 333 can be generated automatically by the ERICA source generator 331 or manually created by the offline application developer. At this time, the format of the project file that is automatically generated is the Visual C ++ 2015 compatible format.

A plurality of main rule source files may be added to the visual C ++ project file 333. [ However, if the main rule source file is added to the visual C ++ project file 333, the source file of the sub rule must be added to the visual C ++ project file 333. [ The list of rule services provided by the rule dynamic link library 336 described later is the same as the list of main rules included in the rule dynamic link library 336. [ Therefore, in order to provide differentiated rule services for each agent, a rule dynamic link library composed of different main rules must be created for each agency.

The ERICA rule server library 334 is a set of codes for performing functions such as a rule API (Application Programming Interface) used for executing a rule, a rule function, and a rule result cache, and is used as a constitution of the rule dynamic link library 336 do.

The task information file 335 is an SQLite data file that stores product information and task information. Through the above process, the product information stored in the rule product information storage unit 312 is converted into a source code by the ERICA source generator 331 and is used to construct a part of the task information file 335, The remaining part of the information file 335 is a part where data received from the task information storage unit 315 is converted into C ++ source code.

The rule dynamic link library 336 is a dynamic link library that provides rule services. The rule dynamic link library 336 is composed of a rule source file 332, a visual C ++ project file 333, and an ERICA rule server library 334 and is built.

According to the embodiment, a rule dynamic link library 336 can be constructed which combines different rule sources and provides different rule services. For example, a rule dynamic link library providing only a premium calculation service using only a premium calculation rule, a rule dynamic link library providing only an acquisition examination service using only an acquisition examination rule, or both services using both types of rules A dynamic link library can be separately constructed.

The rule dynamic link library 336 exports only the rule API functions defined in the ERICA rule server library 334 regardless of the rule source file included in the rule dynamic link library 336. [ That is, all rule dynamic link libraries 336 export the same functions. Thus, one offline application must be distributed with only one rule dynamic link library 336. [

The database engine 337 enables the application developer to easily cope with each time the database (rule product information storage unit) is upgraded through a method of using a pre-built SQLite DLL (dynamic link library).

The offline application 338 is an application that calls a rule service of the rule dynamic link library 336 in an environment separate from the central computerized system 210. The form of the offline application 338 may be an interactive application with a user interface (UI) or a dynamic link library application running on an application server. However, in all of the above cases, the offline application 338 should be a Visual C ++ based application.

The offline environment 350 is an environment that is implemented in the agency server 220 through the developer environment 330 and collects various data providing the finally generated rule service. The offline environment 350 includes a task information file 335, A rule dynamic link library 336, a database engine 337, and an offline application 338. [ According to the configuration included in the offline environment 350, the agent server 220 of FIG. 2 can provide the rule service even in a situation where the network is disconnected from the central computer system 210. In the present invention, a configuration that enables a rule service to be provided through the dealer server 220 even when the network is disconnected is referred to as an independent light rule engine.

4 is a block diagram of another example of a system for generating a lightweight rule engine according to the present invention.

4, a system 400 for creating a lightweight rule engine in accordance with the present invention includes a first system 410 and a second system 430. [ The block diagram of FIG. 4 is a simplified block diagram of the configuration required for implementing the present invention in the central computer system 210 and the developer terminal 215 shown in FIG. 2. Therefore, in addition to the configuration shown in FIG. 4, It is obvious that the present invention can be included in the scope of the present invention if it includes the configuration shown in FIG.

The first system 410 is a system for managing business rules and product information and providing information necessary for building a lightweight rule engine in the second system 430. The system 410 includes a rule server 411, A first data selection unit 415, and a second source data processing unit 417.

The rule server 411 has a function of managing business rules of service goods sold by a service company that performs periodical service such as insurance or bank and has a rule management unit 4111, a rule storage unit 4113, a rule engine 4115).

The rule management unit 4111 generates new business rules and changes (corrects, deletes) existing business rules. When a new business rule is generated, the generated rule is transmitted to the rule storage unit 4113 to be stored. When the existing business rule is changed, the changed rule is updated in the rule storage unit 4113 and stored do.

The rule storage unit 4113 stores business rules constituting the logic of the service goods. Here, the logic of the service product means that, when there is a specific product sold by a bank or an insurance company, and there is a customer inquiring about the product, the personal information of the customer is used as an input value, Is a word collectively representing a process of operating in accordance with a predetermined order in order to calculate a result value according to the above. For example, if the car insurance premium is calculated according to the customer's personal information, the process of calculating the car insurance premium amount according to the customer's personal information can be defined as the logic of the service product, Can be changed by the rule developer. That is, the business rule is information expressed using the reference information of the service goods stored in the goods information system 413. [

Equation (1) is a mathematical expression that the business rule is associated with the reference information of the service goods stored in the goods information system 413. That is, the coefficients for calculating the premium y such as a, b, c are determined by the reference information of the service goods stored in the goods information system 413, and the second, first, The type of service product included and the relationship structure of the service product. The business rule stored in the rule storage unit 4113 includes a constant value added after a, b, and c to calculate premium y, or a total value such as a logic for calculating insurance premium, which is not quadratic but cubic It is variable data depending on changes in market conditions, changes in government policies, and company internal circumstances. The data stored in the product information system 413 and the rule storage unit 4113 can be expressed by Equations 1 and 2 according to the embodiment, It is obvious that it can be changed.

The rule engine 4115 performs a function of reading the rules stored in the rule storage unit 4113, interpreting them, and executing them. The rule engine 4115 reads information on the relationship between the upper node and the lower node included in the rule and, if there is an input value to be applied to the rule, receives the input value and outputs an output value based on the rule And output the output value to the terminal that has transmitted the input value.

Then, the goods information system 413 stores product information (reference information) of the service goods sold by the service company. Here, a service company means a company that sells products that can be implemented based on business rules, such as a company such as an insurance company or a bank. The reference information (product information) of the service product means a parameter indicating the characteristics of the service product. For example, the reference information (product information) Information such as work can be the reference information of a. The product information system 413 links the reference information of the service goods to the code unique to the service product as meta data and stores it in the form of a table.

As an optional embodiment, the reference information of the service goods stored in the goods information system 413 may include the type of the service goods and the relationship structure of the service goods.

The service product type refers to each node classified into a tree structure, which is a concept for managing a service product. The type of the service product includes a specific service product and configuration information of a product constituting the specific service product it means. For example, the type of service product in an insurance product may be a representative product, a commodity, a main contract, a special contract, a security, and the like. As another example, the type of service product in a bank product may be a credit product (real estate mortgage, deposit / secured mortgage), a received product (demand deposit, savings deposit, derivative).

The relation structure of service goods refers to the relationship between the types of service products in hierarchical hierarchy (tree structure). Accordingly, each of the nodes constituting the tree structure can be a type of service goods. For example, in an insurance product, a representative product includes a product, a product includes a main contract and a special contract, and the main contract and the special contract include collateral.

The first data selection unit 415 selects the first format data for the business rule from the data stored in the first system 410 based on a preset condition. The first data selection unit 415 searches the rule storage unit 4113 to store the business rules in the rule storage unit 4113, The user selects a part of the business rules stored in the server.

The first data selection unit 415 includes preset conditions necessary for selecting a business rule stored in the rule storage unit 4113. [ For example, if there is a business rule that is used as a basis for calculating the premium or based on the customer's personal information, the first business rule may be selected by the first data selection unit 415 Can be selected each time.

In an alternative embodiment, the first data selection unit 415 may select not only business rules but also product information based on preset conditions. In this case, the first data selection unit 415 may divide and store a first condition for selecting a rule and a second condition for selecting product information, and the first condition and the second condition may include a business rule and a product And the frequency of calls. 3 that the rule and the product information selected by the first data selection unit 415 are converted into the rule dynamic link library and the task information file by the ERICA source generator, respectively, so that further explanation will be omitted.

The second source data adder 417 converts the first format data selected by the first data selector 415 into the second format source data and transmits the converted second format source data to the second system. Here, the second type source data is data serving as a source of the second type data, and can be constructed as second type data through compiling and linking.

The second system 430 receives information necessary for implementing the lightweight rule engine from the first system 410, and performs a function of building a lightweight rule engine. The second system 430 may include a machining engine calling unit 431 and a second data calculating unit 433.

Processing engine caller 431 receives the second type source data and invokes an embedded rule engine that can compile and link the second type source data. Here, the embedded rule engine is a predefined engine in the machining engine calling unit 431, and performs the function of building the second type source data in the source form into the second type data through the compiling and linking process. As an example, the second type source data may be C or C ++ source code.

When the embedded engine is called, the second data calculating unit 433 calculates second type data for the business rule selected by the first data selecting unit 415 from the second type source data through the embedded engine. The second format data calculated by the second data calculation unit 433 includes information on the same business rule as the first format data, but has a feature that formats for implementing each data are different from each other.

The first type data and the second type data have only different types, and include information on the same kind of business rules. According to the present embodiment, since the first format data is converted from the second format source data to the second format data through the compilation, the second system 430 can only provide the rule service through the business rule, The underlying rule logic of the first system 410 can not be identified at all, resulting in security advantages.

As another optional embodiment, the second type data calculated as described above is a dynamic link library based on C ++, and may be dynamically linked with the business logic and the screen of the second system 430 to configure a sales support application.

5 is a diagram for further illustrating the second format data.

It has already been described that the business rules stored in the rule storage are converted into C ++-based rule source files through the source generator. Since one rule function corresponds to one rule for the readability of the code and the ease of management, the number of rule source files is plural.

The rule source file is compiled and linked through the embedded engine / API called by the second system 430 to form a rule dynamic link library. The rule dynamic link library is dynamically linked with the business logic and the screen, . In other words, to simplify the system architecture, the rule dynamic link library is linked with the sales support application by the dynamic link library method. Here, the sales support application refers to an application installed in the second system 430 so that the second system 430 can provide the rule service to the insurance agent terminal or the like.

The first data selector 415 receives the identification code from the second system 430 and changes the scope of the business rule based on the received identification code, The first format data for the changed business rule can be selected based on a preset condition. That is, according to the present alternative embodiment, the first data selection unit 415 performs primary filtering based on the identification code received from the second system 430 when searching the business rule stored in the rule storage unit 4113 , Only the business rules that satisfy the predetermined conditions are selected from the remaining business rules.

This optional embodiment is an example for providing only one of the premium calculation service and the argument review service according to the agency, or reflecting the characteristics of providing both. According to the present alternative embodiment, the first data selection unit 415 may select the identification code received from the second system 430 to determine whether the second system 430 is an agency server that only performs insurance premium calculation service, It is possible to select the first format data for the business rule according to the identification. In order to implement this embodiment, the second system 430 may receive and store the identification code of the agency or agency server from the agency server 220 in advance.

The second data calculator 433 of the second system 430 calculates the second format data and then transmits the second format data to the dealer server 220. The agency server 220 receives the second format data and provides the enhanced format service to the user terminal (insurance agent terminal) by linking the second format data to the sales support application built in the agency server 220 do. The second format data calculated by the second system 430 may be transmitted to the agency server 220 through a file transfer protocol (FTP) or the like.

The second data calculating unit 433 changes the merchandise information stored in the merchandise information system 413 or the business rule of the rule storage unit 4113 in the first system, If the information necessary for providing the rule service exists, the changed information can be calculated as the second format data and provided to the agent server 220, so that the application developer develops the application of the agent server 220 every time by hard coding no need. It is also possible to receive the second format data through the second system 430 instead of the first system 410 which is different from the system of the general dealer server 220 and to transmit the second format data to the sales support application of the dealer server 220 So that it is possible to easily provide a rule service according to a changed business rule.

In addition, the business rules stored in the central computer system 210 of the insurance company include rules for managing insured persons, rules for paying premiums, rules for calculating insurance premiums for insurance sales, The business rule required for insurance sales 220 is a rule related to insurance premium calculation or acceptance examination required for insurance sales. Therefore, only these rules are selectively processed (dll), so that the rule service can be performed by linking with the sales support application of the dealer server 220 The present invention is superior to the prior art. According to the present invention, since most of the business rules that are dealt with in the central computerized system 210 of the insurer are not stored in the agency server 220, the business rules and business information outflow due to the hacking of the agency server 220 The risk of the disease is greatly reduced.

6 is a flowchart of an example of a method of providing reference information of a service product according to the present invention.

The method according to FIG. 6 can be implemented by the system described with reference to FIG. 2 to FIG. 4, and a description overlapping with the description already described will be omitted.

The first data selector of the first system selects the first format data for the business rule (S610).

The second source data of the first system transforms the first type data into the second type source data (S630).

The second source data of the first system learns and transmits the second type source data to the second system (S650).

The processing engine call unit of the second system calls the embedded rule engine (S670).

The second data calculating unit of the second system calculates the second type data from the second type source data (S690).

As an example of step S690, the second type data may be a dynamic link library (DLL), and may form a sales support application that is dynamically linked with the business logic and screen of the insurance agent reseller server to provide the rule service.

Some foreign insurance companies in Korea and insurance companies operating in Japan are entrusting some of the sales activities such as product introduction and contract to a large number of agencies. In order to support the sales agent of the agency, the insurance company provides the agent with the application to perform the acquisition evaluation and the insurance premium calculation. In this work environment, the agency receives the logic to calculate the insurance fee from the central computer system However, according to the present invention, a standalone lightweight rule engine is constructed in the agency server, so that even when there is a change in the information stored in the central computerized system The information can be easily updated to provide a rule service to a plurality of insurance agent terminals.

According to another aspect of the present invention, there is provided a lightweight rule engine installed in a reseller server, comprising: a business rule management system included in the central computerized system; As there is no need to develop every configuration individually, the cost and duration of developing an application installed by an application developer on a reseller server can be significantly reduced.

The embodiments of the present invention described above can be embodied in the form of a computer program that can be executed on various components on a computer, and the computer program can be recorded on a computer-readable medium. At this time, the medium may be a magnetic medium such as a hard disk, a floppy disk and a magnetic tape, an optical recording medium such as CD-ROM and DVD, a magneto-optical medium such as a floptical disk, , A RAM, a flash memory, and the like, which are specifically configured to store and execute program instructions.

Meanwhile, the computer program may be designed and configured specifically for the present invention or may be known and used by those skilled in the computer software field. Examples of computer programs may include machine language code such as those produced by a compiler, as well as high-level language code that may be executed by a computer using an interpreter or the like.

The specific acts described in the present invention are, by way of example, not intended to limit the scope of the invention in any way. For brevity of description, descriptions of conventional electronic configurations, control systems, software, and other functional aspects of such systems may be omitted. Also, the connections or connecting members of the lines between the components shown in the figures are illustrative of functional connections and / or physical or circuit connections, which may be replaced or additionally provided by a variety of functional connections, physical Connection, or circuit connections. Also, unless explicitly mentioned, such as " essential ", " importantly ", etc., it may not be a necessary component for application of the present invention.

The use of the terms " above " and similar indication words in the specification of the present invention (particularly in the claims) may refer to both singular and plural. In addition, in the present invention, when a range is described, it includes the invention to which the individual values belonging to the above range are applied (unless there is contradiction thereto), and each individual value constituting the above range is described in the detailed description of the invention The same. Finally, the steps may be performed in any suitable order, unless explicitly stated or contrary to the description of the steps constituting the method according to the invention. The present invention is not necessarily limited to the order of description of the above steps. The use of all examples or exemplary terms (e.g., etc.) in the present invention is for the purpose of describing the present invention only in detail, and is not intended to be limited by the scope of the claims. It is not. It will also be appreciated by those skilled in the art that various modifications, combinations, and alterations may be made depending on design criteria and factors within the scope of the appended claims or equivalents thereof.

Claims (10)

A method for implementing a business rule engine on an insurance agent reseller server through a first system and a second system,
A first data selection step in which a first data selection unit included in the first system selects first type data for a business rule from data stored in the first system based on a preset condition;
Transforming the selected first type data into second type source data by which the second source data included in the first system can be constructed by compiling and linking the selected first type data;
A processing engine call included in the second system for receiving the converted second type source data and for calling an embedded rule engine capable of compiling and linking the second type source data; step; And
And a second data calculation unit included in the second system calculates second type data for the business rule from the second type source data via the called embedded engine,
Wherein the second format data includes:
Data for providing a rule service through business rules only in the second system, wherein in the first system, the first type data is constituted of rule logic different from rule logic for providing rule service through a business rule,
Wherein the first data selection step comprises:
The first data selection unit changes the scope of the business rule based on the identification code received from the second system, selects the first format data for the changed business rule on the basis of the preset condition,
The second type source data is source data based on C or C ++,
Wherein the first system and the second system are systems belonging to one intranet,
The above-
Wherein the first system is a condition preset in the first system for selecting first type data for a business rule for at least one of acquisition evaluation or insurance premium calculation in the first system,
The second type data is a dynamic link library based on C ++,
And a sales support application which is dynamically linked with the business logic and the screen of the insurance agent dealer server different from the first system and the second system to provide a rule service to at least one or more user terminals A method for implementing a business rule engine. delete delete delete The method according to claim 1,
Wherein the second format data includes:
Wherein the information is delivered to a server of the insurance company through a file transfer protocol (File Transfer Protocol). A system for implementing a business rule at an insurance agent's server,
The system comprising a first system and a second system,
A first data selection unit that selects first type data for a business rule from data stored in the first system based on a predetermined condition;
Second source data for converting the selected first type data into second type source data capable of building second type data through compiling and linking;
A processing engine calling unit for receiving the converted second type source data and calling an embedded rule engine capable of compiling and linking the second type source data; And
And a second data calculation unit for performing second type data on the business rule from the second type source data through the called embedded engine,
Wherein the first data selector and the second source data are included in the first system,
The machining engine calling unit and the second data calculating unit are included in the second system,
Wherein the second format data includes:
Data for providing a rule service through business rules only in the second system, wherein in the first system, the first type data is constituted of rule logic different from rule logic for providing rule service through a business rule,
Wherein the first data selector comprises:
Changing the range of the business rule based on the identification code received from the second system, selecting the first format data for the changed business rule on the basis of the preset condition,
The second type source data is source data based on C or C ++,
Wherein the first system and the second system are systems belonging to one intranet,
The above-
Wherein the first system is a condition preset in the first system for selecting first type data for a business rule for at least one of acquisition evaluation or insurance premium calculation in the first system,
The second type data is a dynamic link library based on C ++,
And a sales support application which is dynamically linked with the business logic and the screen of the insurance agent dealer server different from the first system and the second system to provide a rule service to at least one or more user terminals A system for implementing business rules. delete delete delete The method according to claim 6,
Wherein the second format data includes:
Wherein the system is delivered to the insurance agent server through a file transfer protocol.

Images