CN118466942A - Business processing system, electronic equipment and server for industrial management - Google Patents

Abstract

The present application provides a business processing system, electronic device and server for industrial software. In the system, a standard component library has several standard components to adapt to the target business processing logic. The front-end interface is used to receive business execution requests and parse them to obtain business logic configuration parameters, so that the background core control layer calls the data interface to obtain the code for running the target business logic based on the business logic configuration parameters and encapsulates it to form an executable script file; the background logic application layer triggers the interaction between the code interpreter interface client and the code interpreter interface server by running the executable script file, so that the background core control layer calls the data interface to obtain the business logic data required for running the executable script file from the background data storage layer, and returns the business logic data to the executable script file through the interaction between the code interpreter interface server and the code interpreter interface client.

Description

Business processing system, electronic equipment and server for industrial management

Technical Field

The present invention relates to the technical field of industrial management software, and in particular to a business processing system, electronic equipment and server for industrial management.

Background Art

The current problems faced by the industrial management software industry are: 1. Large business differences and a high degree of customization; 2. The production and manufacturing process is complex and the amount of data generated is huge; 3. The monthly financial settlement has a strong demand for high-performance data processing.

At present, industrial management software is basically customized and developed according to specific business scenarios to support different differences. For example, PLM, OA, MES, SAP and other systems do not support distributed systems. Therefore, single machines become bottlenecks in large-scale data processing, and are prone to crashes due to memory exhaustion. If there are any problems with the system, the software provider needs to modify it. Among them, although SAP software provides ABAP scripting language, allowing users to perform secondary development for their own business scenarios, ABAP scripting language is not a popular language, there are few practitioners and the development threshold is very high. In addition, ABAP is relatively closed and provides limited functions, which makes it difficult to meet some scenarios; in addition, in the customized development of this code, the degree of code reuse is low, and the development and implementation cycle is very long. A project takes at least 6 months from project establishment to acceptance. Finally, the execution efficiency depends on hardware support. The formal environment memory is more than 600G, and the hardware cost is very expensive.

In addition, the current industrial management software has to be redeveloped after the scene is changed. If the software needs to be adjusted after it is launched, the software supplier needs to modify the code and launch it again. In addition, there are many other disadvantages, including but not limited to:

1. There is no universal architecture design, the code reuse is low, and the development and implementation cycle is long;

2. All functions are hardcoded in the code and do not support secondary development by users;

3. The implementation technology is relatively traditional, does not support distribution, and relies on a single server for support. When the amount of data reaches a certain scale, problems are likely to occur;

4. There is basically no performance optimization, and it relies entirely on server hardware.

Summary of the invention

In order to solve the above technical problems, the present application provides a business processing system, electronic device and server for industrial software to at least solve or alleviate the problems existing in the above-mentioned prior art.

In order to achieve the above purpose, according to one aspect of the present application, a business processing system for industrial management is provided, which includes: a front-end low-code layer, a back-end core control layer built based on C++, a back-end logic application layer built based on Python, and a back-end data storage layer. The front-end low-code layer is deployed on the front-end electronic device, and the back-end core control layer, the back-end logic application layer, and the back-end data storage layer are deployed on the back-end server;

The front-end code layer has a standard component library, the back-end core control layer is deployed with a front-end interface that interacts with the front-end low-code layer, a code interpreter interface server that interacts with the back-end logic application layer, and a data interface that interacts with the back-end data storage layer, and the back-end logic application layer is deployed with a code interpreter interface client that interacts with the back-end core control layer;

The standard component library has a number of standard components to adapt to the target business processing logic, each standard component has a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least includes a business data definition matching the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that a business execution request can be generated based on the dynamic attribute configuration;

The front-end interface is used to receive the business execution request and parse it to obtain business logic configuration parameters, so that the background core control layer calls the data interface based on the business logic configuration parameters to obtain the code for running the target business logic and encapsulates it to form an executable script file;

The background logic application layer triggers the interaction between the code interpreter interface client and the code interpreter interface server by running the executable script file, so that the background core control layer calls the data interface to obtain the business logic data required for running the executable script file from the background data storage layer, and returns the business logic data to the executable script file through the interaction between the code interpreter interface server and the code interpreter interface client.

An electronic device is deployed with a front-end low-code layer, the front-end code layer has a standard component library, the standard component library has a number of standard components to adapt to the target business processing logic, each standard component has a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least includes a business data definition matching the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that a business execution request can be generated based on the dynamic attribute configuration to trigger the background core control layer and the background logic application layer to perform the following processing:

The front-end interface on the background core control layer receives the service execution request and parses it to obtain the service logic configuration parameters, so that the background core control layer calls the data interface of the background core control layer based on the service logic configuration parameters to obtain the code for running the target service logic and encapsulates it to form an executable script file;

The background logic application layer triggers the interaction between the code interpreter interface client on the background logic application layer and the code interpreter interface server on the background core control layer by running the executable script file, so that the background core control layer calls the data interface to obtain the business logic data required for running the executable script file from the background data storage layer, and returns the business logic data to the executable script file through the interaction between the code interpreter interface server and the code interpreter interface client.

A server on which a backend core control layer and a backend logic application layer are deployed to cooperate with a frontend low-code layer deployed on a frontend electronic device to perform the following interactions:

The front-end interface on the background core control layer receives the service execution request and parses it to obtain the service logic configuration parameters, so that the background core control layer calls the data interface of the background core control layer based on the service logic configuration parameters to obtain the code for running the target service logic and encapsulates it to form an executable script file;

The background logic application layer triggers the interaction between the code interpreter interface client on the background logic application layer and the code interpreter interface server on the background core control layer by running the executable script file, so that the background core control layer calls the data interface to obtain the business logic data required for running the executable script file from the background data storage layer, and returns the business logic data to the executable script file through the interaction between the code interpreter interface server and the code interpreter interface client;

Among them, the front-end code layer has a standard component library, which has several standard components to adapt to the target business processing logic, each standard component has static attribute configuration and dynamic attribute configuration, the static attribute configuration at least includes a business data definition that matches the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that the business execution request can be generated based on the dynamic attribute configuration.

A business processing system for industrial management, comprising: a front-end low-code layer, a back-end core control layer, a back-end logic application layer, and a back-end data storage layer;

The front-end code layer has a standard component library, wherein the standard component library has a number of standard components to adapt to the target business processing logic, each standard component has a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least includes a business data definition matching the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that a business execution request can be generated based on the dynamic attribute configuration;

The backend core control layer is used to receive the service execution request and parse it to obtain the service logic configuration parameters, so as to obtain the code for running the target service logic from the backend data storage layer based on the service logic configuration parameters and encapsulate it to form an executable script file;

The background logic application layer runs the executable script file so that the background core control layer calls the data interface to obtain the business logic data required for running the executable script file from the background data storage layer, and returns the business logic data to the executable script file.

To this end, based on the above embodiments of the present application, the following technical benefits are achieved:

(1) By deploying a standard component library on the front-end code layer, these components can be configured and combined according to business needs to quickly build business logic, thereby shortening the development and implementation cycle. In addition, a general business logic processing framework can be built based on the back-end logic application layer, so that code modules in different business scenarios can be reused, improving code reuse.

(2) The separation of the front-end low-code layer and the back-end logic application layer reduces the coupling between the business logic and the front-end interface, allowing the front-end interface to adapt to different business scenarios more flexibly and improving the flexibility and scalability of the system.

(3) By separating the front-end low-code layer and the back-end logic application layer, users can conduct secondary development more conveniently. Users can configure and customize front-end components to achieve different business logic and interaction effects without modifying the underlying code.

(4) The business processing system uses a standard component library deployed on the front-end code layer, allowing users to quickly build and test their own business logic based on existing templates and components, reducing the user's trial and error costs.

(5) The business processing system uses a backend core control layer built in C++ and a backend logic application layer built based on Python, allowing users to perform secondary development of the system based on actual needs. Users can implement specific business logic by modifying configurations, adding custom components, or writing custom scripts.

(6) Since multiple distributed nodes can be deployed based on the background core control layer and the background logic application layer, it supports distributed deployment and elastic scaling, and can automatically adjust resource allocation according to data volume and business needs to cope with large-scale data demand scenarios.

(7) The business processing system is based on the technical interaction and cooperation of the front-end low-code layer, the back-end core control layer built based on C++, the back-end logic application layer built based on Python, and the back-end data storage layer when processing specific business logic. When optimizing performance, it only needs to be optimized at the software level, reducing the dependence on server hardware.

BRIEF DESCRIPTION OF THE DRAWINGS

The drawings constituting a part of this application are used to provide a further understanding of this application, so that other features, purposes and advantages of this application become more obvious. The schematic embodiment drawings and their descriptions of this application are used to explain this application and do not constitute an improper limitation on this application. In the drawings:

FIG1 is a schematic diagram of the architecture of a business processing system for industrial management according to an embodiment of the present application.

DETAILED DESCRIPTION

In order to enable those skilled in the art to better understand the solution of the present application, the following will be combined with the drawings in the embodiments of the present application to clearly and completely describe the technical solutions in the embodiments of the present application. Obviously, the described embodiments are only part of the embodiments of the present application, not all of the embodiments. Based on the embodiments in the present application, all other embodiments obtained by ordinary technicians in this field without creative work should fall within the scope of protection of this application.

The solution provided by the following embodiments of the present application has the following technical advantages:

(1) By deploying a standard component library on the front-end code layer, these components can be configured and combined according to business needs to quickly build business logic, thereby shortening the development and implementation cycle. In addition, a general business logic processing framework can be built based on the back-end logic application layer, so that code modules in different business scenarios can be reused, improving code reuse.

(2) The separation of the front-end low-code layer and the back-end logic application layer reduces the coupling between the business logic and the front-end interface, allowing the front-end interface to adapt to different business scenarios more flexibly and improving the flexibility and scalability of the system.

(3) By separating the front-end low-code layer and the back-end logic application layer, users can conduct secondary development more conveniently. Users can configure and customize front-end components to achieve different business logic and interaction effects without modifying the underlying code.

(4) The business processing system uses a standard component library deployed on the front-end code layer, allowing users to quickly build and test their own business logic based on existing templates and components, reducing the user's trial and error costs.

(5) The business processing system uses a backend core control layer built in C++ and a backend logic application layer built based on Python, allowing users to perform secondary development of the system based on actual needs. Users can implement specific business logic by modifying configurations, adding custom components, or writing custom scripts.

(6) Since multiple distributed nodes can be deployed based on the background core control layer and the background logic application layer, it supports distributed deployment and elastic scaling, and can automatically adjust resource allocation according to data volume and business needs to cope with large-scale data demand scenarios.

(7) The business processing system is based on the technical interaction and cooperation of the front-end low-code layer, the back-end core control layer built based on C++, the back-end logic application layer built based on Python, and the back-end data storage layer when processing specific business logic. When optimizing performance, it only needs to be optimized at the software level, reducing the dependence on server hardware.

Figure 1 is a schematic diagram of the structure of an industrial management business processing system provided by an embodiment of the present application. As shown in Figure 1, it includes: a front-end low-code layer, a back-end core control layer built based on C++, a back-end logic application layer built based on Python, and a back-end data storage layer. The front-end low-code layer is deployed on the front-end electronic device, and the back-end core control layer, back-end logic application layer, and back-end data storage layer are deployed on the back-end server;

The front-end code layer has a standard component library, the back-end core control layer is deployed with a front-end interface that interacts with the front-end low-code layer, a code interpreter interface server that interacts with the back-end logic application layer, and a data interface that interacts with the back-end data storage layer, and the back-end logic application layer is deployed with a code interpreter interface client that interacts with the back-end core control layer;

The standard component library has a number of standard components to adapt to the target business processing logic, each standard component has a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least includes a business data definition matching the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that a business execution request can be generated based on the dynamic attribute configuration;

The front-end interface is used to receive the business execution request and parse it to obtain business logic configuration parameters, so that the background core control layer calls the data interface based on the business logic configuration parameters to obtain the code for running the target business logic and encapsulates it to form an executable script file;

The background logic application layer triggers the interaction between the code interpreter interface client and the code interpreter interface server by running the executable script file, so that the background core control layer calls the data interface to obtain the business logic data required for running the executable script file from the background data storage layer, and returns the business logic data to the executable script file through the interaction between the code interpreter interface server and the code interpreter interface client.

Optionally, a business logic processing class is configured on the code interpreter interface client to instantiate the business logic processing class when the executable script file is run in the background logic application layer to obtain the business logic configuration parameters to trigger the interaction between the code interpreter interface client and the code interpreter interface server based on the business logic configuration parameters.

Optionally, a data source configuration is performed for the static attribute configuration to assign the request address of the business execution request and the request parameters included in the business request to obtain the dynamic attribute configuration, wherein the request parameters include: the name of the code corresponding to the target business logic, and the business processing method triggered by the target business logic in the code.

To this end, data source configuration is performed for static attribute configuration to allocate the request address and request parameters of the business execution request, thereby obtaining dynamic attribute configuration, which has the following technical benefits:

(1) The data source is configured through static attribute configuration. The request address of the business execution request is clearly specified, ensuring that the business logic can accurately and efficiently find the corresponding backend service interface during the processing.

(2) The request parameters include the name of the code corresponding to the target business logic and the triggered business processing method. This parameterized configuration method enables the system to dynamically adjust the request parameters according to different business logics, thereby improving the flexibility and configurability of the system.

(3) The request address and request parameters are assigned through data source configuration instead of hard coding in the code, making the code clearer and easier to maintain. When the business logic changes, only the configuration information needs to be modified without modifying and recompiling the code.

(4) Since the request address and request parameters have been predefined and assigned through static attribute configuration, when a business execution request arrives, the system can quickly parse the request and call the corresponding business logic processing method, thereby improving the efficiency of business logic processing.

(5) Through data source configuration, the system can easily add new business logic and processing methods by simply adding corresponding entries in the configuration file, without making large-scale modifications to the system architecture. This design makes the system more scalable and able to adapt to the ever-changing business needs.

(6) Since the configuration of the request address and request parameters is static, the system can preload and cache them at startup, reducing the dynamic parsing and search time at runtime, thereby optimizing the system performance.

Optionally, the background data storage layer stores a Python code list and a Python code content list, each code in the Python code maintenance list corresponds to a unique ID, and the Python code content list includes the unique ID of each code and the content string representation of the code. The background core control layer accesses the Python code maintenance list through the data interface based on the business logic configuration parameters and determines the unique ID of the code, obtains the content string corresponding to the code in the Python code content list based on the unique ID, and encapsulates the content string to form the executable script file.

To this end, when the backend data storage layer stores the Python code list and its contents and associates them through a unique ID, it has the following technical benefits:

(1) By assigning a unique ID to each Python code and managing it in a code maintenance list, the system can efficiently track, manage, and maintain the code. This management method makes code addition, deletion, modification, and query operations simple and fast.

(2) Based on the business logic configuration parameters, the backend core control layer can quickly access the Python code maintenance list through the data interface and directly locate the corresponding code content based on the unique ID. This fast retrieval mechanism greatly reduces the time for code search and loading, and improves the system's response speed.

(3) The Python code content list stores the unique ID of each code and the corresponding content string representation. This ensures that the backend core control layer can accurately obtain the corresponding code content after obtaining the unique ID of the code, avoiding errors caused by code content mismatch.

(4) After obtaining the code content, the backend core control layer can encapsulate it into an executable script file. This dynamic encapsulation method enables the system to dynamically generate and execute corresponding script files according to different business logic configuration parameters, thereby improving the flexibility and scalability of the system.

(5) By storing Python code in the background data storage layer and accessing and encapsulating it through the data interface, the security of the code can be effectively protected. Only authorized and verified requests can access the code content, reducing the risk of code leakage and malicious exploitation.

(6) Since each code has a unique ID, the system can easily implement version control. When you need to roll back to the previous code version, you only need to find the corresponding code content based on the unique ID. This version control mechanism makes the system more robust and reliable.

Optionally, the background core control layer is also used to determine the environment variables, configuration file path, initialize database connection, and input parameters required to run the executable script file to create an execution context for the executable script file, and create a startup code based on the execution context to trigger the running of the executable script file by running the startup code.

The backend core control layer has the following technical benefits in the process of determining the environment variables, configuration file paths, initializing database connections, input parameters, and creating an execution context to trigger script execution required to run the executable script file:

(1) By explicitly setting environment variables and configuration file paths, you can ensure that executable script files run in the same, consistent environment, thereby reducing operational errors and uncertainties caused by environmental differences.

(2) Initializing the database connection ensures that the script can successfully access database resources during runtime. It also provides database connection reuse and management functions, improving data access efficiency and security.

(3) The setting of input parameters allows the script to be flexibly configured and called according to different business scenarios and requirements, improving the reusability and configurability of the script.

(4) By creating and executing contexts, the backend core control layer can uniformly manage the script's running environment, including environment variables, configuration files, database connections, and input parameters, making the script execution process clearer and more controllable.

(5) Create startup code based on the execution context, and trigger the execution of the script by running the startup code. This dynamic startup mechanism allows the system to dynamically load and execute scripts as needed, improving the flexibility and responsiveness of the system.

(6) In the process of managing the execution context, error handling and logging mechanisms can be easily added so that problems can be discovered and located in a timely manner when they occur during script execution, thereby improving the robustness and maintainability of the system.

(7) By managing the execution context, the background core control layer can more efficiently utilize system resources such as memory, CPU, and IO, thereby improving the overall performance and throughput of the system.

(8) By managing sensitive information such as database connections and input parameters, the backend core control layer can provide more secure data access control and permission management functions to prevent unauthorized access and data leakage.

Optionally, the background logic application layer generates an SQL statement and sends the SQL statement to the interpreter interface server of the background core control layer through the interpreter interface client, so that the interpreter interface server calls the data interface to execute the SQL statement to obtain the business logic data required to run the executable script file from the background data storage layer.

To this end, the backend logic application layer sends SQL statements to the interpreter interface server of the backend core control layer through the interpreter interface client, and then executes the SQL statements to obtain the business logic data required to run the executable script file from the backend data storage layer, which has the following technical benefits:

(1) Using SQL as the standard language for data access ensures the consistency and maintainability of data access. Different business logic application layers can access the backend data storage layer through a unified SQL interface, reducing the complexity of system integration.

(2) SQL statements are a language designed specifically for database queries. They can be used to efficiently retrieve, update, and delete data from the backend data storage layer. This efficient data access mechanism makes business logic processing faster and more accurate.

(3) By executing SQL statements on the server side through the interpreter interface, data access can be controlled and filtered on the server side, thereby enhancing data security. The server side can verify the legitimacy of SQL statements and prevent security attacks such as malicious SQL injection.

(4) The backend logic application layer and the backend core control layer communicate through the interpreter interface, achieving loose coupling between the two layers. This loosely coupled architecture makes the system more flexible, easy to expand and maintain. When the business logic changes, only the code of the backend logic application layer needs to be modified, without modifying the code of the backend core control layer.

(5) Since the standard SQL interface is used for data access, the backend data storage layer can be easily replaced with other SQL-supported database systems. This portability enables the system to flexibly adapt to different business needs and technical environments.

(6) By executing SQL statements on the server side through the interpreter interface of the backend core control layer, the utilization of system resources can be optimized. The server side can parse and optimize SQL statements, reduce unnecessary database operations, and improve the overall performance of the system.

(7) The backend logic application layer is responsible for generating SQL statements and sending requests, while the backend core control layer is responsible for executing SQL statements and returning results. This clear division of responsibilities makes system development and maintenance easier and reduces development and maintenance costs.

Optionally, the business processing system further comprises: at least one of a standard operator layer or a standard business logic flow layer, wherein the standard operator layer comprises encapsulated standard business processing operators, and the standard business logic flow layer comprises encapsulated standard business logic flows;

Correspondingly, when the startup code is run to trigger the runtime of the executable script file, the background logic application layer, through the interaction between the code interpreter interface client and the code interpreter interface server, passes the standard business parameters adapted to the target business logic into the standard business processing operator and/or the standard business logic flow to trigger the execution of the business logic data and/or the standard business processing operator and the standard business logic flow and obtain the execution result, and then returns the execution result to the executable script file through the interaction between the code interpreter interface client and the code interpreter interface server. The standard business parameters are obtained from the business execution request, or obtained from the background data storage layer by constructing SQL statements, or obtained from the cache of the background core control layer.

To this end, a standard operator layer or a standard business logic flow layer is introduced into the business processing system, and adapted standard business parameters are passed through the code interpreter interface when executing the executable script file. This has the following technical benefits:

(1) The standard operator layer encapsulates common, reusable business processing operators, while the standard business logic flow layer encapsulates common business processing flows. This encapsulation allows business logic to be reused in different scripts and scenarios, improving code reusability and development efficiency.

(2) By passing adapted standard business parameters to standard business processing operators or standard business logic flows, the execution mode and parameter values of business logic can be flexibly configured. This enables the system to quickly adjust business logic according to different business needs and scenarios, improving the flexibility and adaptability of the system.

(3) By splitting the business logic into standard operators and logic flows, the business logic processing is clearer and easier to understand. This helps reduce code complexity and maintenance costs, and improves the maintainability and testability of the system.

(4) The standard operator layer and standard business logic flow layer provide an extensible framework that allows easy addition of new business processing operators and logic flows. When business requirements change, it is only necessary to add or modify operators or logic flows at the corresponding level without making large-scale modifications to the entire system.

(5) By encapsulating business logic in operators or logic flows and separating data access logic through SQL statements and database interfaces, the business logic and data access are decoupled. This allows the system to process data more flexibly and improves the security and efficiency of data access.

(6) Through the cache mechanism, the system can quickly obtain commonly used standard business parameters, reducing the time to obtain data from the data storage layer. At the same time, due to the reuse and configuration of business logic, unnecessary calculations and logical judgments can be reduced, further improving the execution efficiency of the system.

(7) Due to the encapsulation and abstraction of the standard operator layer and the standard business logic flow layer, the business logic is relatively independent of the specific implementation technology (such as database, programming language, etc.). This makes it easier to migrate the system to different technology platforms or environments.

Optionally, the business processing system further comprises: at least one of a standard operator layer or a standard business logic flow layer, wherein the standard operator layer comprises encapsulated standard business processing operators, and the standard business logic flow layer comprises encapsulated standard business logic flows;

Correspondingly, the running of the startup code triggers the running of the executable script file, the background logic application layer generates an SQL statement, and sends the SQL statement to the code interpreter interface server through the interaction between the code interpreter interface client and the code interpreter interface server to obtain the business logic data from the background data storage layer through the data interface;

The background core control layer passes the standard business parameters adapted to the target business logic into the standard business processing operator and/or the standard business logic flow to obtain the execution result, and loads the obtained business logic data and the execution result into the executable script file through the interaction between the code interpreter interface server and the code interpreter interface client to run the executable script file in the background logic application layer.

To this end, a standard operator layer or a standard business logic flow layer is introduced into the business processing system. In the process of executing the executable script file, data is interacted through the code interpreter interface and SQL statements, and the adapted standard business parameters are passed to the standard business processing operator or the standard business logic flow to execute and obtain the execution results, and then these results are loaded into the executable script file. This has the following technical benefits:

(1) The introduction of the standard operator layer and the standard business logic flow layer enables the reuse and standardization of business logic. This means that developers can reuse existing business logic components instead of having to write them from scratch every time, greatly improving development efficiency.

(2) Business logic data is obtained from the backend data storage layer through SQL statements, and business logic and data storage are decoupled. This design allows the system to process data from different sources more flexibly, and also facilitates data maintenance and updating.

(3) By adapting the standard business parameters of the target business logic, the system can flexibly configure the execution mode and parameter values of the business logic. This enables the system to be quickly adjusted according to different business needs and scenarios, improving the flexibility and adaptability of the system.

(4) Due to the existence of the standard operator layer and the standard business logic flow layer, the system can select the optimal algorithm and process to process business logic at runtime, thereby optimizing the performance of the system. In addition, through technical means such as caching mechanisms, unnecessary calculations and database access can be further reduced, thereby improving the response speed of the system.

(5) The encapsulation and abstraction of the standard operator layer and the standard business logic flow layer make the system easier to maintain and expand. When business requirements change, only the corresponding operators or logic flows need to be modified without making large-scale modifications to the entire system. At the same time, this design also makes the system easier to understand and test.

(6) By interacting with data and instructions through the code interpreter interface, data can be verified and filtered on the server side to prevent security attacks such as malicious SQL injection. At the same time, due to the decoupling of business logic and data access, the system can also more easily implement security control and permission management.

(7) Through the encapsulation of standard business logic flows, the system can support more complex business logic processing flows. These flows can be implemented by combining and calling different standard business processing operators to meet more diverse business needs.

Optionally, the standard operator layer or the standard business logic flow layer is deployed on the background core control layer based on C++.

Optionally, the background data storage layer is deployed with a structured database and a cache database, the structured database is used for business logic data, and the cache database is used to cache hot data in the business logic data when executing target business logic data;

Correspondingly, the data interface includes a structured database interface and a cache database interface, so as to shield the direct interaction between the target business logic and the structured database or the cache database when obtaining the business logic data from the structured database or the cache database, so that the code corresponding to the target business logic can be kept unchanged when the structured database and the cache database are switched in type.

To this end, a structured database and a cache database are deployed in the background data storage layer, and the direct interaction between the target business logic and the database is shielded through data interfaces (including structured database interfaces and cache database interfaces), which has the following technical benefits:

(1) The cache database is used to store hot data in business logic data. These hot data are usually data with high access frequency and low update frequency. By storing hot data in the cache database, the number of accesses to the structured database can be significantly reduced, the database load can be reduced, and the overall system performance can be improved.

(2) By abstracting the data storage logic into a data interface, the underlying data storage technology can be easily switched without modifying the business logic code. This means that the system can more flexibly adapt to different data storage requirements, such as switching from a relational database to a non-relational database, or introducing new caching technologies.

(3) By accessing and operating data through the data interface, data can be verified and filtered on the server side to prevent malicious attacks and data leakage. At the same time, the cache database can be used as a backup of the structured database. When the structured database fails, data can be restored from the cache database to ensure data integrity and security.

(4) Since the cache database stores hot data, when this data is frequently accessed, it can be directly obtained from the cache database without having to go through the network to obtain it from the structured database. This can significantly reduce network traffic, reduce network load, and improve system response speed.

(5) The abstraction of the data interface allows developers to focus on the implementation of business logic without having to worry about the details of the underlying data storage technology. This can reduce development difficulty, improve development efficiency, and also facilitate code maintenance and expansion.

(6) The data interface can be used to conveniently monitor and record data access and operation conditions, which is very helpful for troubleshooting and performance monitoring. At the same time, since the data interface is separated from the business logic code, the problem can be more clearly located, improving the efficiency of troubleshooting.

Optionally, when obtaining the business logic data from the structured database or the cache database, the data interface creates a connector to trigger an executor to execute an SQL statement for obtaining business logic data to obtain the business logic data from the structured database, or executes a cache command string to obtain the business logic data from the cache database, and destroys the connector after obtaining the business logic data.

To this end, when obtaining business logic data from a structured database or cache database, a connector is created through a data interface to trigger the executor to execute SQL statements or cache command strings, and the connector is destroyed after the data is obtained. This has the following technical benefits:

(1) The connector will be destroyed immediately after acquiring data, which means that the system will not occupy these resources for a long time. This "use it and forget it" strategy helps reduce the consumption of system resources and improve resource utilization.

(2) Since the connector is destroyed immediately after acquiring data, it cannot be used by malicious users or programs to continue to access the database. This helps prevent potential security risks such as SQL injection attacks.

(3) Since the creation and destruction of connectors are dynamic, the system can dynamically adjust the number of connectors as needed. During peak hours, more connectors can be created to handle more requests; during off-peak hours, the number of connectors can be reduced to save resources. This dynamic adjustment capability makes the system more flexible and scalable.

(4) Each connector is independent. If one connector encounters a problem when acquiring data (such as database failure, network interruption, etc.), other connectors will not be affected. This fault isolation feature helps maintain the stability and reliability of the system.

(5) For developers, they do not need to care about the underlying details such as the creation, use and destruction of connectors. They only need to send requests and receive results through the data interface. This simplified programming model reduces the complexity of development and improves development efficiency.

Optionally, a connection pool is established on the background core control layer, and the connection pool caches the created connectors so that when obtaining the business logic data, the connection pool is queried to see whether there is an available connector. If so, the available connector is directly used as the created connector; otherwise, the step of creating a connector is executed.

To this end, a connection pool is established on the background core control layer, and the created connectors are cached so that these connectors can be reused when obtaining business logic data. This has the following technical benefits:

(1) By reusing connectors, you can avoid frequent creation and destruction of connections, thereby reducing the overhead of connection establishment and closing. This helps improve the system's responsiveness and throughput, especially in high-concurrency scenarios.

(2) The connection pool can limit the number of concurrent connections, thereby preventing excessive connection requests from exhausting system resources. At the same time, through reasonable configuration and management, it can ensure that the system always maintains a certain number of available connections to meet business needs.

(3) The connectors in the connection pool are all verified and initialized, so using them can reduce errors and failures caused by connection problems. In addition, the connection pool can also implement connection failover and load balancing, further improving the reliability and stability of the system.

(4) Developers do not need to worry about the underlying details of connector creation, use, and destruction. They only need to obtain the connector from the connection pool and send a request. This simplified programming model reduces development complexity and improves development efficiency.

(5) Connectors in the connection pool can pre-establish connections with the database and keep these connections active. This helps reduce the overhead of database connections and improve the efficiency of database access.

(6) The connection pool is designed to be modular and can be easily expanded and adjusted to suit different business scenarios and needs. At the same time, since the connection pool is centrally managed, it can be more easily monitored and maintained.

Optionally, the connection pool monitors the cumulative idle time of the connectors cached therein, and if the recorded cumulative idle time of the connectors exceeds a set cumulative time threshold, the idle connectors are destroyed to reclaim connector resources.

To this end, the idle cumulative time of the connector is monitored in the connection pool, and the connector is destroyed to recycle resources when the idle cumulative time exceeds the set threshold. This has the following technical benefits:

(1) By monitoring the cumulative idle time of connectors, the system can identify connectors that have not been used for a long time and destroy them to release the occupied resources. This helps to avoid waste of resources and improve the resource utilization of the system.

(2) Destroying long-idle connectors can reduce unnecessary connections in the system, thereby reducing the system's overhead in maintaining these connections. This helps improve the overall performance of the system, especially in high-concurrency scenarios, by reducing resource competition and conflicts.

(3) Connectors that are idle for a long time may pose potential security risks or connection failure problems. By destroying these connectors, the system can reduce these risks and improve system stability and security.

(4) When the system load increases, the connection pool can quickly create new connectors to meet demand. When the system load decreases, the connection pool can shrink to meet current demand by destroying idle connectors. This scalability enables the system to flexibly respond to different business scenarios and needs.

(5) The unified management and maintenance of connectors through the connection pool can simplify the work of system administrators. Administrators do not need to manually manage the life cycle of each connector, but only need to configure the parameters of the connection pool to achieve automatic management.

(6) Developers do not need to worry about the underlying details such as the creation and destruction of connectors. They only need to obtain connectors through the connection pool to develop business logic. This reduces the complexity of development and improves development efficiency.

Optionally, the background core control layer and the background logic application layer form a plurality of distributed nodes in a one-to-one correspondence manner. When the target business logic includes a plurality of target business sub-logics, the background logic application layer creates a plurality of subtasks corresponding to the plurality of target business sub-logics when running the executable script file, and based on the interaction between the code interpreter interface client and the code interpreter interface server, calls the data interface deployed on the background core control layer to cache the plurality of subtasks to the background data storage layer;

Correspondingly, the multiple distributed nodes cooperate in the following manner to execute the multiple target logic sub-logics in parallel: multiple threads are created on the background core control layer in each distributed node, and each thread on each distributed node consumes a subtask to trigger the background logic application layer of each distributed node to execute a target business sub-logic.

To this end, the backend core control layer and the backend logic application layer are organized into multiple distributed nodes in a one-to-one correspondence. When executing the target business logic containing multiple target business sub-logics, subtasks are created, subtasks are cached using the data interface, and these subtasks are executed in parallel on multiple distributed nodes. This has the following technical benefits:

(1) By splitting the target business logic into multiple subtasks and executing these subtasks in parallel on multiple distributed nodes, the system's processing capacity can be significantly improved. Each distributed node can process multiple subtasks at the same time, thus making full use of the system's hardware resources.

(2) The design of distributed nodes allows the system to be easily expanded to cope with higher loads. When the business logic becomes more complex or the amount of data processed increases, the system's processing capacity can be increased by adding more distributed nodes.

(3) Since each distributed node is independent, the failure of one node will not affect the operation of other nodes. In addition, by caching subtasks in the data storage layer, even if a node fails, other nodes can continue to obtain subtasks from the data storage layer and execute them, thus ensuring the fault tolerance and reliability of the system.

(4) By separating the backend core control layer from the backend logic application layer, distributed nodes can be configured and managed more flexibly. For example, different business logics can be deployed to different nodes according to different business needs, or the node configuration can be dynamically adjusted according to the node load.

(5) By creating subtasks and executing them in parallel, complex business logic can be split into multiple simple tasks. This allows developers to focus more on the implementation of a single task, reducing the complexity of development. At the same time, since each distributed node is independent, the node can be upgraded and maintained individually without affecting the operation of the entire system.

(6) By properly allocating and managing resources (such as CPU, memory, and disk space) on distributed nodes, it is possible to ensure maximum utilization of system resources. For example, the amount of resources allocated to a node can be dynamically adjusted based on the load of each node, or idle resources can be used to process other tasks.

In addition, in the above embodiments, C++ and Python are used as examples for illustration, but in other possible application scenarios, other combinations may also be used, such as Java, Go with Python or Lua, etc.

Based on any of the above embodiments, the embodiments of the present application also provide an electronic device, on which a front-end low-code layer is deployed, and the front-end code layer has a standard component library, and the standard component library has several standard components to adapt to the target business processing logic, each standard component has a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least includes a business data definition that matches the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that a business execution request can be generated based on the dynamic attribute configuration to trigger the background core control layer and the background logic application layer to perform the following processing: the front-end interface on the background core control layer receives the business execution request and parses it to obtain the business logic configuration parameters number, so that the background core control layer calls the data interface of the background core control layer based on the business logic configuration parameters to obtain the code for running the target business logic and encapsulates it to form an executable script file; the background logic application layer triggers the interaction between the code interpreter interface client on the background logic application layer and the code interpreter interface server on the background core control layer by running the executable script file, so that the background core control layer calls the data interface to obtain the business logic data required for running the executable script file from the background data storage layer, and returns the business logic data to the executable script file through the interaction between the code interpreter interface server and the code interpreter interface client.

Here, the exemplary explanation of each feature of the above electronic device can refer to the above description of Figure 1. In addition, the form of the electronic device is not limited, and it can be a mobile device, or a desktop computer, notebook computer, or any other device that can implement the present application.

Based on any of the above embodiments, the embodiments of the present application also provide a server on which a background core control layer and a background logic application layer are deployed to cooperate with the front-end low-code layer deployed on the front-end electronic device to perform the following interaction: the front-end interface on the background core control layer receives the business execution request and parses it to obtain the business logic configuration parameters, so that the background core control layer calls the data interface of the background core control layer based on the business logic configuration parameters to obtain the code for running the target business logic and encapsulates it to form an executable script file; the background logic application layer triggers the interaction between the code interpreter interface client on the background logic application layer and the code interpreter interface server on the background core control layer by running the executable script file. The front-end code layer and the back-end code layer interact with each other, so that the back-end core control layer calls the data interface to obtain the business logic data required for running the executable script file from the back-end data storage layer, and returns the business logic data to the executable script file through the interaction between the code interpreter interface server and the code interpreter interface client; wherein, the front-end code layer has a standard component library, the standard component library has several standard components to adapt to the target business processing logic, each standard component has a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least includes a business data definition that matches the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that the business execution request can be generated based on the dynamic attribute configuration.

Here, the exemplary explanation of each feature of the above server can refer to the above description of Figure 1. In addition, the form of the server is not limited.

Based on any of the above embodiments, an embodiment of the present application also provides a business processing system for industrial management, which includes: a front-end low-code layer, a back-end core control layer, a back-end logic application layer, and a back-end data storage layer; the front-end code layer has a standard component library, wherein the standard component library has several standard components to adapt the target business processing logic, each standard component has a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least includes a business data definition that matches the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that a business execution request can be generated based on the dynamic attribute configuration; the back-end core control layer is used to receive the business execution request and parse it to obtain business logic configuration parameters, so as to obtain the code for running the target business logic from the back-end data storage layer based on the business logic configuration parameters and encapsulate it to form an executable script file; the back-end logic application layer runs the executable script file so that the back-end core control layer calls the data interface to obtain the business logic data required to run the executable script file from the back-end data storage layer, and returns the business logic data to the executable script file.

Here, the exemplary explanation of each feature in the business processing system for business management can be found in the above description of FIG. 1 .

The above description is only a preferred embodiment of the present application and an explanation of the technical principles used. Those skilled in the art should understand that the scope of the invention involved in the present application is not limited to the technical solution formed by a specific combination of the above technical features, but should also cover other technical solutions formed by any combination of the above technical features or their equivalent features without departing from the above invention concept. For example, the above features are replaced with the technical features with similar functions disclosed in this application (but not limited to) by each other.

Claims (10)

1. An industrial administration business processing system, comprising: the system comprises a front-end low-code layer, a background core control layer built based on C++, a background logic application layer built based on Python and a background data storage layer, wherein the front-end low-code layer is deployed on front-end electronic equipment, and the background core control layer, the background logic application layer and the background data storage layer are deployed on a background server;

The front end code layer is provided with a standard component library, the background core control layer is provided with a front end interface which interacts with the front end low code layer, a code interpreter interface service end which interacts with the background logic application layer and a data interface which interacts with the background data storage layer, and the background logic application layer is provided with a code interpreter interface client which interacts with the background core control layer;

The standard component library is provided with a plurality of standard components to adapt to the target service processing logic, each standard component is provided with a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least comprises a service data definition matched with the target service logic, and the dynamic attribute configuration is configured based on the behavior of the target service logic, so that a service execution request can be generated based on the dynamic attribute configuration;

The front-end interface is used for receiving the service execution request and analyzing the service execution request to obtain service logic configuration parameters, so that the background core control layer calls the data interface to obtain codes for running the target service logic based on the service logic configuration parameters and encapsulates the codes to form an executable script file;

And the background logic application layer triggers interaction between the code interpreter interface client and the code interpreter interface server through running the executable script file, so that the background core control layer calls the data interface to acquire service logic data required by running the executable script file from the background data storage layer, and returns the service logic data to the executable script file through interaction between the code interpreter interface client and the code interpreter interface client.

2. The business processing system of claim 1, wherein data source configuration is performed for said static attribute configuration to allocate a request address of said business execution request, request parameters included in said business request to obtain said dynamic attribute configuration, said request parameters comprising: and the target service logic corresponds to the name of the code, and the target service logic triggers the service processing method in the code.

3. The business processing system of claim 1, wherein the background data storage layer stores a Python code list and a Python code content list, each code corresponds to a unique ID in the Python code maintenance list, the Python code content list includes the unique ID of each code and a content string representation of the code, the background core control layer accesses the Python code maintenance list through the data interface based on the business logic configuration parameters and determines the unique ID of the code, obtains the content string corresponding to the code in the Python code content list based on the unique ID, and encapsulates the content string to form the executable script file.

4. The business processing system of claim 1, wherein the background data storage layer is configured with a structured database and a cache database, the structured database is used for business logic data, and the cache database is used for caching hot spot data in the business logic data when executing target business logic data;

Correspondingly, the data interface comprises a structured database interface and a cache database interface, so that when the business logic data is acquired from the structured database or the cache database, the direct interaction between the target business logic and the structured database or the cache database is shielded, and the codes corresponding to the target business logic can be kept unchanged when the structured database and the cache database are subjected to type switching.

5. The business processing system of claim 4, wherein upon retrieving the business logic data from the structured database or the cache database, the data interface creates a connector to trigger an executor to execute an SQL statement that retrieves business logic data to retrieve the business logic data from the structured database or a cache command string to retrieve the business logic data from the cache database and destroys the connector after the business logic data is retrieved.

6. The business processing system of claim 5, wherein a connection pool is established on the background core control layer, wherein the connection pool is cached with created connectors, so that when the business logic data is acquired, whether available connectors exist in the connection pool is inquired, if yes, the available connectors are directly used as the created connectors, and otherwise, the step of creating connectors is executed.

7. The business processing system of any of claims 1-6, wherein the background core control layer and the background logic application layer form a plurality of distributed nodes in a one-to-one correspondence manner, when the target business logic comprises a plurality of target business sub-logics, the background logic application layer creates a plurality of sub-tasks corresponding to the plurality of target business sub-logics when running the executable script file, and invokes the data interface deployed on the background core control layer to cache the plurality of sub-tasks to the background data storage layer based on interaction between the code interpreter interface client and the code interpreter interface server;

Correspondingly, a plurality of the distributed nodes cooperate to execute the plurality of target logic sub-logics in parallel in the following manner: creating multiple threads on a background core control layer in each distributed node, wherein each thread on each distributed node consumes a subtask to trigger a background logic application layer of each distributed node to execute a target service sub-logic.

8. An electronic device having a front-end low-level code disposed thereon, the front-end level code having a library of standard components thereon, the library of standard components having a number of standard components to adapt to the target business process logic, each standard component having a static attribute configuration including at least a business data definition matching the target business logic and a dynamic attribute configuration configured based on the behavior of the target business logic such that a business execution request can be generated based on the dynamic attribute configuration to trigger a background core control layer and a background logic application layer to perform the following processing:

The front-end interface on the background core control layer receives the service execution request and analyzes the service execution request to obtain service logic configuration parameters, so that the background core control layer calls a data interface of the background core control layer to obtain codes for running the target service logic based on the service logic configuration parameters and encapsulates the codes to form an executable script file;

and the background logic application layer triggers interaction between a code interpreter interface client side on the background logic application layer and a code interpreter interface server side on the background core control layer by running the executable script file, so that the background core control layer calls the data interface to acquire service logic data required by running the executable script file from a background data storage layer, and returns the service logic data to the executable script file through interaction between the code interpreter interface client side and the code interpreter interface client side.

9. A server having a background core control layer and a background logic application layer disposed thereon to perform the following interactions in cooperation with a front-end low-code layer disposed on a front-end electronic device:

The front-end interface on the background core control layer receives and analyzes the service execution request to obtain service logic configuration parameters, so that the background core control layer calls a data interface of the background core control layer to obtain and package codes of operation target service logic based on the service logic configuration parameters to form an executable script file;

the background logic application layer triggers interaction between a code interpreter interface client side on the background logic application layer and a code interpreter interface service side on the background core control layer through running the executable script file, so that the background core control layer calls the data interface to acquire service logic data required by running the executable script file from a background data storage layer, and returns the service logic data to the executable script file through interaction between the code interpreter interface service side and the code interpreter interface client side;

The front-end code layer is provided with a standard component library, the standard component library is provided with a plurality of standard components to adapt to the target business processing logic, each standard component is provided with a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least comprises business data definition matched with the target business logic, and the dynamic attribute configuration is configured based on the behavior of the target business logic, so that the business execution request can be generated based on the dynamic attribute configuration.

10. An industrial administration business processing system, comprising: a front end low code layer, a background core control layer, a background logic application layer and a background data storage layer;

The front-end code layer is provided with a standard component library, wherein the standard component library is provided with a plurality of standard components to adapt to the target service processing logic, each standard component is provided with a static attribute configuration and a dynamic attribute configuration, the static attribute configuration at least comprises a service data definition matched with the target service logic, and the dynamic attribute configuration is configured based on the behavior of the target service logic, so that a service execution request can be generated based on the dynamic attribute configuration;

The background core control layer is used for receiving the service execution request and analyzing the service execution request to obtain service logic configuration parameters, so that codes for operating the target service logic are obtained from the background data storage layer based on the service logic configuration parameters and are packaged to form an executable script file;

the background logic application layer enables the background core control layer to call the data interface to acquire business logic data required by running the executable script file from the background data storage layer by running the executable script file, and returns the business logic data to the executable script file.