CN114816360A - Dynamic service configuration system - Google Patents

Abstract

The invention provides a set of dynamic business configuration system, which comprises five modules, namely a configuration center management page, a public embedded page, an API service layer, a rule engine and a high-cohesion data model. The workflow scheme based on page embedding, unified management of service configuration data and dynamic generation of the target page is designed, so that the problems of excessive human resource occupation, complex data maintenance, overlong development period and the like of a conventional configuration system are effectively solved.

Description

Dynamic Business Configuration System

technical field

The invention relates to the fields of Internet technology and financial business, and in particular to a dynamic business configuration system based on front-end and back-end technology stacks such as vue and java.

Background technique

Based on the system positioning of the business, the core system needs to continuously expand and enrich business scenarios on the basis of providing stable and scalable basic capabilities to the business, so that the upper-level business can quickly implement various configuration methods based on the core capabilities.

The existing core has provided more than 20 business scenario functions to the business, including more than 100 business attribute fields. The existing core system empowers the business in the following ways: each business side team needs to go through R&D tests on its operating system and add the required business scenarios to realize the configuration of business rules. And all the business rule configuration information is landed on the target during the actual business transaction, so that the core system can identify and implement the back-end logic according to the configured rules.

The main disadvantages of the existing solutions are:

The scene capabilities required by each business team need to be developed separately each time, and the data is stored separately in order to realize the configuration of functions, and there is a lot of repeated construction;

Each business team needs to understand the business logic of the core back-end to realize the front-end interaction logic. Cross-team communication is prone to inconsistency in communication and understanding, and the mismatch between the implementation logic and the back-end leads to systemic risks;

Any transformation of the core system involves the business system, which has high coupling and affects the whole body;

The scenarios under each business rule of the core system and the 100+ fields that make up the scenarios are not managed in a standardized manner, resulting in high daily maintenance costs.

Therefore, we have developed a new dynamic configuration management system to solve the problems caused by the repeated research and development of each team in the process of empowering the core system to the business, the high coupling with the business and the lack of focus, and the mismatch between the implementation logic of the business system and the core logic. Sexual risks and low project delivery efficiency.

SUMMARY OF THE INVENTION

The problem to be solved by the present invention is to overcome the problems existing in the prior art and provide a dynamic service configuration system.

In order to solve the above problems, the technical scheme of the present invention is as follows:

Dynamic business configuration system, including five modules: configuration center management page, public embedded page, API service layer, rule engine, and cohesive data model;

Configuration Center Management Page

Dynamically generate a set of public pages by configuring elements, scenes, templates and rule constraints;

public embed page

The form is represented as a link, which is generated by the configuration center management page, and the business access party renders the configuration through iframe embedding;

API service layer

An RPC system based on http protocol and post data format developed in java language, the system supports addition, deletion, modification, and query operations on configuration data;

rules engine

A series of special identifiers are formulated for the representation type, data format, and value range of the elements, and a constraint check is carried out for these identifiers;

Cohesive Data Model

A data model composed of elements, scenarios, templates, constraint rules and business modules.

In the configuration center management page, the operator configures basic element information, scene information, and template information on the management page, and performs rule-constrained configuration control. After the configuration is completed, the system will dynamically generate an embedded url for business use.

The public embedded page is embedded in the module of the business system by the user through the embedded link generated by the configuration center management page, so that the business system directly renders the page operation entry of the unified configuration center.

When the business party triggers the save/modify event in its independent business system, it will indirectly trigger the save/modify event embedded in the public page of the configuration center, and the public page of the configuration center will call the API service layer to add and delete data. The configuration center will return a ConfigId to the business system to save, establishing a real relationship between the business and the configuration center.

The API service layer is developed using the Java language spring framework, and the cloud native deployment method; the interface layer of the API service layer includes element addition, deletion and modification, group addition, deletion and modification, template addition and deletion, scene addition, deletion and modification, rule constraint processing, and common basic configuration. Query, business configuration data query operation module.

The rule engine implements element rule check and feasibility judgment among elements or groups; including checksum judgment of special keys, constraints, operators, value types, and value-limited types.

Special keys include: and, or;

Constraints include: left, operator, right, right_is_prop, fail_msg;

Operator operators include: in, >=>==<<=! =, regular, length;

Value types include: json collection, numeric value, string, json object;

Value-qualified types include: numeric, enum, and string.

The cohesive data model uses the mysql database as the storage software and the cloud machine as the medium.

The cohesive data model is divided into modules according to elements, scenarios, templates, constraint rules and services.

In the cohesive data model, the model information fields include: element id, element name, scene id, scene name, template id, template name, constraint type, business configId, creation time, creator, and status.

Beneficial effects:

1. Through the techniques of componentization mechanism, operation embedding and digital-analog isolation, it effectively solves the problems of high complexity, high R&D cost, time-consuming, insufficient data security and inflexible and efficient operation of the previous business configuration system.

2. Technically, the performance and development and maintenance problems caused by traditional BS technology selection (such as jsp, php, bootstrap, jquery, etc.) are eliminated. By adopting the most popular front-back separation and dynamic responsive design, combined with cloud-native architecture deployment, it achieves the goals of high service performance, high availability, low maintenance costs, and easy expansion of functions.

The present invention will be described in detail below with reference to the accompanying drawings and specific embodiments.

Description of drawings

FIG. 1 is a schematic diagram of the architecture of the dynamic service configuration system according to the present invention.

FIG. 2 is a rule engine table of the dynamic service configuration system according to the present invention.

FIG. 3 is a diagram showing the operation relationship of the rule engine of the dynamic service configuration system according to the present invention.

FIG. 4 is a configuration diagram of basic fields/components of the configuration center management page according to the present invention.

FIG. 5 is a configuration diagram of the public embedded page according to the present invention.

FIG. 6 is a logical diagram of the API service layer according to the present invention.

FIG. 7 is a data model diagram according to the present invention.

FIG. 8 is a flow chart of the rule ID according to the present invention.

FIG. 9 is a flow chart of service implementation of the dynamic service configuration system according to the present invention.

Detailed ways

In order to make it easy to understand the technical means, creation features, achievement goals and effects of the present invention, the present invention will be further described below with reference to the specific figures.

system structure:

According to the functional positioning of each module, the system is divided into operation access layer, service layer, core layer (including rule engine), and DB storage layer. The upper layer of the system is connected to the business, and the lower layer handles the core tasks; the upper layer can make differential adaptation adjustments to different services, and the core layer is stable. (figure 1)

Abbreviations and key terms are defined as follows:

Vue: Vue is a progressive framework for building user interfaces. Unlike other large frameworks, Vue is designed to be applied layer by layer from the bottom up. Vue's core library only focuses on the view layer, which is not only easy to use, but also easy to integrate with third-party libraries or existing projects.

JS: JavaScript ("JS" for short) is a lightweight, interpreted or just-in-time compiled programming language with function first. Although it is famous as a scripting language for developing Web pages, it is also used in many non-browser environments. JavaScript is a dynamic scripting language based on prototype programming, multi-paradigm, and supports object-oriented, imperative, declarative, functional programming paradigm.

HTML: the full name of Hypertext Markup Language, is a markup language. It includes a series of tags. Through these tags, the document format on the network can be unified, and the scattered Internet resources can be connected as a logical whole. HTML text is descriptive text composed of HTML commands, which can describe text, graphics, animations, sounds, tables, links, and more.

Cascading Style Sheets (English full name: Cascading Style Sheets) is a computer language used to represent document styles such as HTML (an application of Standard Universal Markup Language) or XML (a subset of Standard Universal Markup Language). CSS can not only modify web pages statically, but also dynamically format various elements of web pages with various scripting languages. CSS can perform pixel-level precise control over the layout of element positions in web pages, supports almost all font size styles, and has the ability to edit web page objects and model styles.

Java: An object-oriented programming language, it not only absorbs various advantages of C++ language, but also abandons the incomprehensible concepts of multiple inheritance and pointers in C++. Therefore, Java language has two characteristics of powerful functions and ease of use. As a representative of static object-oriented programming language, Java language perfectly implements object-oriented theory, allowing programmers to perform complex programming in an elegant way of thinking.

Element: It is the atomic content that constitutes each configuration scenario, and is the minimum condition in business activities/rules.

Group: refers to a set of several elements or conditions, which are bound in a set form, and multiple sets of rules can be configured so that the backend can implement the logic of business rule A "or" B.

Scenario: Refers to a collection of all conditions in a business activity.

Template: It means that business activities can set rules according to a fixed format, and multiple/single scenarios can generate a template.

Rule ID: Based on the template, the unique value generated by the business operator after completing the business rule configuration. The rule ID corresponds to all the rule configuration details (see Figure 8)

Rule engine: A series of special identifiers are formulated for the representation type, data format, value range, etc. of the elements, and constraint verification is performed on these identifiers (see Figure 2-3).

Technical Implementation Steps

Configuration center management page: When using, first configure the basic fields (that is, the basic components of the public embedded page), you can set the field storage type, the business party to which it belongs, and the display type; you can configure templates according to these basic fields, and you can configure business rules between fields to achieve different interactive functions. (See Figure 4)

Common Embed Pages: Common embed pages, built from different form components. When the business party accesses, the entrance is unified, and pages composed of different components are displayed by passing in different template ids. To reduce the development work of front-end code (see Figure 5).

API service layer: a set of api service layer system based on http protocol and post data format developed in java language, the system provides support for adding, deleting, modifying and checking configuration data, and divides sub-modules according to different usage scenarios. When providing basic data capabilities, we also considered the business configuration association query interface, through which the only association entry between the actual business and the configuration system is opened. When adding and updating configuration data, the system will trigger the execution of the rule engine to perform unified verification and constraint processing on the data (see Figure 6).

Cohesive data model: The configuration center system needs to be compatible with the use of various business scenarios, and has the constraints of independent systems, so the construction of digital models is relatively high. We start from the minimum granularity configuration data, abstract the element information table, and then derive the scene model, and then derive the template model through the scene model. We encapsulate these major models as the basic data model, and add the rule engine constraint model and the specific business configuration data model on top of the basic model, thereby reducing the coupling between business, strategy, and basic data. The entire model has clear boundaries, is easy to expand and maintain, and is also easy to correct abnormal data. When the model is not fully suitable for business changes, we can update the business model and stabilize the core basic model. Technically, we use cloud mysql storage technology to save data, with a complete backup mechanism, data security is guaranteed (see Figure 7).

Service access steps

First, the upstream business will evaluate the required business activity configuration management capabilities and make demands to the configuration center.

Next, the configuration center administrator will create all the elements or groups required for the corresponding business activities in the configuration center operation system, and configure the interaction logic between each element or group, the content of the verification rules, etc., one by one according to the business logic. Scenes. Configure multiple scenarios into templates, and generate corresponding template IDs and page links.

After the business system obtains the corresponding template ID and page link, it completes the R&D test work of embedding the page link corresponding to the module ID and configuring the ID storage in the operating system of the upstream business itself.

At this point, the business access work has been completed, and if there is any capacity expansion and change of the core system in the future, there is no need to involve the business system.

business implementation logic

First, the upstream business operation system configures all business rules, and sends the [Save] command to the configuration center. After the configuration center verifies that the configuration data is correct, it saves the configuration details, generates a rule ID and returns it to the upstream business side, where the business side saves it. The relationship between the good rule ID and the business side.

Then, when an actual transaction occurs, the rule ID or all the rule configuration details corresponding to the rule ID will be stored in the business order information.

Finally, the core system will execute the code logic according to the rules details in the obtained business order information in each process of the business logic implementation, and no longer rely on the business system in the whole process.

The service implementation process (Figure 9), in this embodiment, the configuration center system has two access service systems, and the migration and use of more than 20 types of service configurations has been successfully completed. There are 0 accidents caused by online configuration data, saving production, research and testing. The labor cost is 3 people, which greatly improves the R&D efficiency and R&D quality, and effectively avoids the risk of configuration data security and the delay of emergency projects due to configuration.

The foregoing has shown and described the basic principles, main features and advantages of the present invention. Those skilled in the art should understand that the present invention is not limited by the above-mentioned embodiments. The above-mentioned embodiments and descriptions only illustrate the principle of the present invention. Such changes and improvements fall within the scope of the claimed invention. The scope of patent protection for the present invention is defined by the appended claims and their equivalents.

Claims (10)

1. The dynamic service configuration system is characterized by comprising: the system comprises five modules, namely a configuration center management page, a public embedded page, an API service layer, a rule engine and a cohesive data model;

configuration center management page

Dynamically generating a set of public pages by configuring elements, scenes, templates and rule constraints;

public embedded page

The form is expressed as a link, the link is configured and generated by a configuration center management page, and a service access party renders the configuration in an iframe embedding mode;

API service layer

An RPC system developed by using java language and based on http protocol and post data format supports the operations of adding, deleting, modifying and checking configuration data;

rules engine

A series of special identifiers are formulated according to the expression types, data formats and numerical ranges of the elements, and meanwhile, the identifiers are subjected to constraint verification;

cohesive data model

And the data model is composed according to the elements, the scene, the template, the constraint rule and the business module.

2. The dynamic service configuration system according to claim 1, wherein the configuration center management page is configured by an operator to configure basic element information, scenario information, and template information on the management page, and perform rule-constrained configuration control on the basic element information, the scenario information, and the template information, and after the configuration is completed, the system dynamically generates an embedded url for service use.

3. The dynamic service configuration system according to claim 2, wherein the common embedded page is embedded into a module of the service system through an embedded link generated by the configuration center management page by a user, so that the service system directly renders a page operation entry of the unified configuration center.

4. The dynamic service configuration system according to claim 3, wherein when the service party triggers the save/modify event in its independent service system, the save/modify event embedded in the public page in the configuration center is indirectly triggered, the public page in the configuration center separately calls the API service layer to add or delete data, and after the execution is successful, the configuration center returns a ConfigId identifier to the service system for saving, thereby establishing the real relationship between the service and the configuration center.

5. The dynamic business configuration system of claim 1, wherein the API service layer is developed in a practical java language spring framework, cloud-based deployment; the interface layer of the API service layer comprises element addition and deletion, group addition and deletion, template addition and deletion, scene addition and deletion, rule constraint processing, public basic configuration query and service configuration data query operation modules.

6. The dynamic business configuration system of claim 1, wherein the rules engine, implements element rule checksum feasibility determinations between elements or groups; including checksum determinations for special keys, constraint terms, operator operators, value types, and value limit types.

7. The set of dynamic service provisioning systems of claim 6,

the special key includes: and, or;

the constraint items include: left, operator, right _ is _ prop, fail _ msg;

operator operators include: in, or ═ in! Renular, length;

the value types include: json set, numerical value, character string, json object;

the value definition types include: numeric values, enumerations, strings.

8. The dynamic business configuration system of claim 1, wherein the cohesive data model uses a mysql database as storage software and a cloud machine as a medium.

9. The dynamic business configuration system of claim 8 wherein the cohesive data model partitions modules according to elements, scenarios, templates, constraint rules, and businesses.

10. The dynamic service configuration system of claim 9, wherein the cohesive data model, model information field, comprises: element id, element name, scene id, scene name, template id, template name, constraint type, service configId, creation time, creator, status.

Images