Disclosure of Invention
The invention provides a method for identifying a rule engine adapter device facing business personnel, which aims to solve the problems that the business personnel are difficult to use the rule engine and difficult to seamlessly joint with a business system.
A method for identifying a business person-oriented rule engine adapter device comprises the following steps:
step 1: defining the interface message format of DSL, and defining the attributes including a rule variable library, an operator, a variable type, a data type and a message structure element;
step 2: defining a client side SDK based on java language, and defining conversion logic comprising an RPC protocol, an embedded WEB container, JSON and DSL, wherein the SDK is interacted with a rule engine server side;
and step 3: defining a rule design interface based on HTML, wherein the definition comprises an interface style, a data form, a message format and a message transmission mode;
and 4, step 4: loading the SDK containing the lightweight WEB container into a service system, and accessing and using a rule designer in the SDK by service personnel through an HTTP link;
and 5: defining a mapping logic of JSON data and DSL messages in an SDK packet of a client, and converting input rule data into messages in a DSL format so as to facilitate a rule engine server to identify and construct a rule model;
step 6: and defining the mapping logic of JSON data and JAVA class objects in the client side SDK package, wherein the mapping logic is used for storing input data according to fields, and is convenient for a front end HTML interface to display stored rule data.
Compared with the prior art, the invention has the beneficial effects that: 1. the invention can be used as an adapting device of a universal rule engine designer, meets the requirements of developers on-line simulation test, version control and rule model real-time change without modifying codes, and also meets the characteristics of simple operation and seamless integration with a service system for service personnel through the conversion of an adapter.
2. The invention can seamlessly embed the rule engine interface into the service system management background, provides a form type rule design interface, facilitates the online real-time creation and change of rules by service personnel, and provides a monitoring interface for the execution state of the rules.
Detailed Description
The technical solutions in the embodiments of the present invention will be clearly and completely described below with reference to the drawings in the embodiments of the present invention, and it is obvious that the described embodiments are only a part of the embodiments of the present invention, and not all of the embodiments. All other embodiments, which can be derived by a person skilled in the art from the embodiments given herein without making any creative effort, shall fall within the protection scope of the present invention.
Referring to fig. 1, the method for identifying a business-oriented rule engine adapter device according to the present invention includes the following steps:
step 1: defining the interface message format of DSL, and defining the attributes including a rule variable library, an operator, a variable type, a data type and a message structure element; rule metadata such as rule-set, rule, import-variable-library, etc., also including count, avg, sum, max, and, or, etc.;
an interface is designed by defining rules facing WEB forms and is used for converting a complex graphical data interface into a more concise DSL interface;
step 2: defining a client side SDK based on java language, and defining conversion logic comprising an RPC protocol, an embedded WEB container, JSON and DSL, wherein the SDK is interacted with a rule engine server side;
business personnel generally carry out business operation and management through a business management system, and the design of business rules is also defined as a part of business operation; the rule engines of most banks as a shared basic platform can be commonly used by a plurality of business systems, the rule engines and the business systems can also be responsible for different departments, and the seamless connection between the rule designer and the business systems directly influences the fluency of business personnel using the rule engines; and step 2, the client side SDK based on the java language is defined, and because the SDK comprises the lightweight WEB container, the rule designer can be directly used and can be seamlessly connected to the service system as long as the SDK is loaded into the service system, and the service system does not need to consider the problems of rule designer integration and deployment.
And step 3: defining a rule design interface based on HTML, wherein the definition comprises an interface style, a data form, a message format and a message transmission mode;
and 4, step 4: the SDK containing the lightweight WEB container is loaded into a service system, and service personnel access and use a rule designer in the SDK through an HTTP link.
The rule designer interface based on the HTML form is deployed in an embedded WEB container in the client side SDK, and the rule designer can be accessed and used through an HTTP link as long as the service system loads the SDK. The design has two main purposes, namely, the rule designer can be seamlessly embedded into a business system, and business personnel can use the rule designer conveniently; and secondly, extra deployment of a service system or code level embedding rule designers are avoided, and the purpose of instant use is achieved. And the business personnel can operate more simply by defining a rule design interface based on HTML.
And 5: defining a mapping logic of JSON data and DSL messages in an SDK packet of a client, and converting input rule data into messages in a DSL format so as to facilitate a rule engine server to identify and construct a rule model;
rule data input by business personnel from an HTML rule designer is packaged in a universal JSON format on a front-end page, but a DSL message interface is provided by a rule engine server, and the JSON format needs to be converted into DSL and then submitted to the rule engine server. The client side SDK undertakes the message conversion work from JSON to DSL. The design is mainly to avoid exposing some technical details of the rule engine to the business system, and the business system only needs to use the rule designer without paying attention to internal implementation details.
Step 6: and defining the mapping logic of JSON data and JAVA class objects in the client side SDK package, wherein the mapping logic is used for storing input data according to fields, and is convenient for a front end HTML interface to display stored rule data.
The rule designer based on HTML provides the capability of creating rules, and needs to consult and change the rules, and when creating the rules, the rule engine server side constructs the rule factors into a rule model and then stores the whole rule model into a relational database. If business personnel want to consult or change the rule model, the complex rule model needs to be parsed into a series of rule factors. Thus, in order for the rule designer to easily review and alter the rule model, there are two parallel paths during rule creation, as depicted in step 5: one is that after the rule factor is constructed into a rule model, the whole rule model is stored in a relational database for subsequent rule service invocation; the other path is that as described in step 6, the rule factors input by the service personnel are directly stored in the relational database, the service personnel consult the rules and directly read the original rule factors, and when the rules are changed, the data of the two paths need to be changed at the same time.
In the step 1, according to the rule engine modeling requirement based on the RETE algorithm, the rule variables, data and computation logic are expressed as messages in the DSL format, and the message categories include, but are not limited to, rule-set, rule, import-variable-library rule metadata and count, avg, sum, max, and or operators.
In the step 2, the rule design interface used by the service-oriented personnel is packaged in the client SDK, and the rule design interface is operated by an embedded web container; the data input from the rule design interface is converted into a message in a DSL format by JSON and DSL conversion logic, and then is transmitted to the rule engine server by an RPC protocol.
In the step 3, the HTML-based rule design interface is customized according to actual service requirements, so that a client can directly access the interface after starting, and can conveniently embed the interface into a service management system in a link form, code intrusion on an original system cannot be caused, and the plug-and-play mode is very convenient.
In the step 5, the data of the front-end rule design interface is transmitted to the client side SDK in the JSON format, and after the data is processed through JSON-to-DSL logic in the SDK, the rule data is finally transmitted to the rule engine server side in the DSL format through the RPC protocol to construct the rule model.
In the step 6, the front-end rule design interface needs to display the existing rule data in the database besides inputting the data; therefore, the original data in the front-end JSON format is converted into Java objects in the client SDK, and then the Java objects are stored in a relational database according to fields and used for displaying a front-end rule design interface; the rule data displayed by the front end is simpler.
It will be evident to those skilled in the art that the invention is not limited to the details of the foregoing illustrative embodiments, and that the present invention may be embodied in other specific forms without departing from the spirit or essential attributes thereof. The present embodiments are therefore to be considered in all respects as illustrative and not restrictive, the scope of the invention being indicated by the appended claims rather than by the foregoing description, and all changes which come within the meaning and range of equivalency of the claims are therefore intended to be embraced therein. Any reference sign in a claim should not be construed as limiting the claim concerned.
Furthermore, it should be understood that although the present description refers to embodiments, not every embodiment may contain only a single embodiment, and such description is for clarity only, and those skilled in the art should integrate the description, and the embodiments may be combined as appropriate to form other embodiments understood by those skilled in the art.