A digital service operating system supporting multi-service scenarios

Abstract

This invention relates to the field of digital business technology and discloses a digital business operating system supporting multiple business scenarios. The system includes: a metadata modeling module that parses database table structures and uses entity description structure data as a unified data reference source; a page construction module that determines mapping relationships based on page component fields and entity fields, and determines data instances corresponding to entity identifiers based on these mapping relationships; a process scheduling module that parses pre- and post-dependencies and conditional expressions based on process definition structure data, performs rule matching processing when executing nodes containing conditional expressions, and performs permission matching processing when executing resource access nodes; a rule service module that performs rule matching calculations based on rule unit version identifiers; and a cloud-native runtime module that performs instance deployment, scheduling, and inter-service communication management based on a container orchestration controller. This invention meets the performance stability and scalability requirements of digital businesses in multiple business scenarios.

Description

Technical Field

[0001] This invention relates to the field of digital business technology, and more specifically, to a digital business operating system that supports multiple business scenarios. Background Technology

[0002] As enterprises deepen their digital transformation, business needs are becoming increasingly diversified in terms of scenarios and complex in terms of processes. Enterprise-level business systems are gradually evolving from single-function applications to integrated digital business platforms that cover multiple business scenarios, all business processes, and provide unified collaboration. This places higher demands on the development efficiency, scenario adaptability, operational flexibility, and cross-role collaborative development of business systems. However, traditional enterprise-level business systems adopt a customized code development model, which suffers from long development cycles, low delivery efficiency, and complex heterogeneous technology stacks. Upgrade and maintenance costs are high, and it is difficult to quickly respond to dynamically changing business needs. At the same time, access control adopts a role-based configuration approach, which cannot adapt to the refined and dynamic control needs of multiple business entities, multiple resource types, and multiple operational dimensions, and there are security risks in data access and resource operations. Because page visualization construction, business process orchestration, and rule logic configuration are independent of each other, and the process orchestration and rule engine are not linked, business logic configuration is fragmented, making it impossible to form a full-link development capability that integrates data, pages, processes, and rules. Furthermore, the platform architecture is based on a monolithic architecture or a traditional distributed architecture design, which does not support deployment capabilities such as containerization and encapsulation, making it difficult to meet the performance stability and scalability requirements under multiple business scenarios, resulting in insufficient development efficiency.

[0003] Therefore, it is necessary to design a digital business operating system that supports multiple business scenarios to solve the problems existing in the current technology. Summary of the Invention

[0004] In view of this, the present invention proposes a digital business operating system that supports multiple business scenarios. It aims to solve the problems of the lack of linkage between process orchestration and rule engine, fragmented business logic configuration, inability to form a full-link development capability integrating data, pages, processes and rules, platform architecture that does not support deployment capabilities such as containerization and encapsulation, difficulty in meeting the performance stability and scalability requirements of multiple business scenarios, and resulting in insufficient development efficiency.

[0005] This invention proposes a digital service operating system that supports multiple service scenarios, comprising: The metadata modeling module is configured to parse the database table structure, generate entity description structure data containing entity identifiers, field attributes, and entity relationships, and use the entity description structure data as a unified data reference source. The page building module is configured to determine page structure definition data based on the entity description structure data, and determine the mapping relationship based on page component fields and entity fields. After receiving business data, it determines the data instance corresponding to the entity identifier based on the mapping relationship. The process scheduling module is configured to parse the pre- and post-dependent relationships and conditional expressions based on the process definition structure data, determine the node topology, determine the process instance identifier based on the data instance, sort the node topology to determine the node execution sequence, perform rule matching processing when executing a node containing the conditional expression, and perform permission matching processing when executing a node accessing resources. The rules service module is configured to receive data from the page building module and the process scheduling module, and perform rule matching calculations based on the rule unit version identifier; The cloud-native runtime module is configured to encapsulate the metadata modeling module, page building module, process scheduling module, and rule service module, and to perform instance deployment, scheduling, and inter-service communication management based on the container orchestration controller.

[0006] Furthermore, when parsing the database table structure, the process includes: the metadata modeling module reading the database metadata, extracting field names, field types, constraints, and foreign key relationships, constructing a set of field attributes based on the field names and field types, constructing an entity association mapping table based on the foreign key relationships, integrating the set of field attributes and the entity association mapping table, and determining the entity description structure data.

[0007] Furthermore, when determining a data instance, the process includes: the page building module reading the field attribute set and mapping the field attribute set to the page component type set; determining page component parameters based on the field types; establishing a mapping relationship between the page component parameters and entity fields; and reorganizing the business data based on the mapping relationship to determine the data instance.

[0008] Furthermore, when determining the node execution sequence, the process includes: the process scheduling module reads the node identifier, node type, and node dependency information from the process definition structure data, constructs a node adjacency matrix based on the node dependency information, constructs a directed graph on the node adjacency matrix to determine the node topology, performs a loop check on the node topology, generates a node sorting list if no loop dependency exists, and binds the data instance to the node sorting list to determine the process instance identifier and the corresponding node execution sequence.

[0009] Furthermore, when executing a node containing the conditional expression, the process includes: the process scheduling module determining rule matching parameters based on the conditional expression and sending the rule matching parameters to the rule service module; the rule service module loading the corresponding rule version based on the rule unit version identifier and performing a conditional comparison operation on the rule matching parameters; returning a node path identifier based on the comparison result; and the process scheduling module updating the node execution sequence based on the node path identifier.

[0010] Furthermore, when executing a node for resource access, the process includes: the process scheduling module extracting the identity identifier and the resource identifier, reading the permission set data based on the identity identifier, and performing a matching operation between the permission set data and the resource identifier. When the matching result is "access allowed", a node execution flag is generated; when the matching result is "access denied", a node termination flag is generated. The node execution flag or node termination flag is then written into the status record corresponding to the process instance identifier.

[0011] Furthermore, when writing the status record corresponding to the process instance identifier, the process scheduling module reads the rule matching result and the permission matching result, generates data parameters containing node identifier, execution timestamp and node execution, and numbers the data parameters according to the node execution order to determine the node execution sequence record dataset. Based on the process instance identifier, the node execution sequence record dataset is integrated to determine the execution trajectory data chain.

[0012] Furthermore, the digital business operating system supporting multiple business scenarios also includes: the cloud-native runtime module obtaining the process instance identifier and the corresponding execution trajectory data chain, structurally encapsulating the execution trajectory data chain to determine the runtime data object, and mapping the runtime data object to a container instance.

[0013] Furthermore, when mapping the runtime data object to a container instance, the process includes: the cloud-native runtime module reading the runtime status data of the corresponding container, the runtime status data including the instance number, load parameters and resource allocation parameters, associating and storing the load parameters and process instance identifier, and determining the instance scheduling record data.

[0014] Furthermore, when mapping the runtime data object to container instances, the cloud-native runtime module adjusts the number of container replicas based on the container orchestration controller, generates replica expansion instructions or replica reduction instructions based on the adjustment results, and reallocates the mapping relationship between containers and process instance identifiers.

[0015] Compared with existing technologies, the advantages of this invention are as follows: Parsing the database table structure and generating entity description structure data as a unified data reference source avoids the problems of chaotic data sources and heterogeneous data between modules in traditional systems, reducing the amount of customized code development, thereby shortening the development cycle and reducing upgrade and maintenance costs. Based on the entity description structure data, it realizes the mapping between page component fields and entity fields, generating corresponding data instances without the need for manual writing of association code, improving the efficiency of building business pages. Based on node execution sequence sorting, rule matching processing, and permission matching processing, it achieves deep linkage between process orchestration and rule logic, improving the fragmented nature of business logic configuration. The system addresses these issues by employing refined permission matching to meet the dynamic management needs of multiple business entities, resource types, and operational dimensions. Rule matching calculations are performed based on rule unit version identifiers, enabling centralized management of rule logic. This builds a full-chain development capability integrating data, pages, processes, and rules. Furthermore, by encapsulating and relying on a container orchestration controller to complete instance deployment, scheduling, and inter-service communication management, the system possesses containerized deployment capabilities. This overcomes the limitations of monolithic architecture and traditional distributed architecture, improving the system's performance stability and scalability across multiple business scenarios while also considering development efficiency, thus meeting the development requirements of full-stack business systems for enterprises. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 This is a functional block diagram of a digital business operating system that supports multiple business scenarios, provided as an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] To make the above-mentioned objects, features and advantages of the present invention more apparent and understandable, the present invention will be further described in detail below with reference to the accompanying drawings and specific embodiments.

[0020] See Figure 1As shown in some embodiments of this application, a digital service operating system supporting multiple service scenarios includes: The metadata modeling module is configured to parse the database table structure, generate entity description structure data containing entity identifiers, field attributes, and entity relationships, and use the entity description structure data as a unified data reference source. The page building module is configured to determine the page structure definition data based on the entity description structure data, and to determine the mapping relationship based on the page component fields and entity fields. After receiving business data, it determines the data instance corresponding to the entity identifier based on the mapping relationship. The process scheduling module is configured to parse the pre- and post-dependencies and conditional expressions based on the process definition structure data, determine the node topology, determine the process instance identifier based on the data instance, sort the node topology to determine the node execution sequence, perform rule matching processing when executing nodes containing conditional expressions, and perform permission matching processing when executing resource access nodes. The rules service module is configured to receive data from the page building module and the process scheduling module, and perform rule matching calculations based on the rule unit version identifier; The cloud-native runtime module is configured to encapsulate the metadata modeling module, page building module, process scheduling module, and rule service module, and to manage instance deployment, scheduling, and inter-service communication based on the container orchestration controller.

[0021] Specifically, the database table structure is the organizational form of tables in an enterprise database used to store various business data, including the various data fields contained in the table and the relationship between fields. The metadata modeling module performs a comprehensive and detailed analysis of the database table structure, sorting out the information of each data entity, and then generating entity description structure data containing entity identifiers, field attributes, and entity relationships. The entity identifier is used to uniquely distinguish different data entities in the system. For example, in enterprise business, the "customer" entity and the "order" entity each have a unique entity identifier to avoid confusion between different entities. Field attributes are the relevant characteristics of each data field in the database table structure, such as the field name, data type, and whether it is a required field. Entity relationships are the association logic between different data entities. For example, between the "customer" entity and the "order" entity, one customer can correspond to multiple orders. This one-to-many correspondence is the entity relationship. The metadata modeling module uses the generated entity description structure data as the unified data reference source for the entire digital business operating system. This means that all other modules in the system can obtain data-related information from this entity description structure data without multiple data sources. This avoids the problems of chaotic data sources and inconsistent data between different modules in traditional enterprise business systems, thereby reducing development and maintenance costs caused by data redundancy and conflicts. The page construction module uses the entity description structure data to determine the page structure definition data. The page structure definition data is used to standardize the layout, component distribution, and display style of business pages, such as which input boxes, buttons, and tables should be included on the page, and their order. The page construction module determines the mapping relationship based on page component fields and entity fields. Page component fields are the field information corresponding to each component on the page. For example, the "Customer Name Input Box" component on the page corresponds to the "Customer Name" field. Entity fields are the fields in the entity description structure data that contain the corresponding data entities, such as the "Customer Name" field in the "Customer" entity. The mapping relationship between the two ensures a one-to-one correspondence between page components and underlying data fields, guaranteeing that page components can accurately obtain and display the corresponding business data.Once the page building module receives the actual business data generated by the enterprise, it filters out the business data corresponding to each entity identifier based on the previously established mapping relationship. This then determines the data instance corresponding to each entity identifier. A data instance is specific data bound to a particular entity identifier and containing actual business content. For example, in the "Customer" entity, the data instance corresponding to the entity identifier "Customer 001" is a set of data containing actual information such as the customer's name, contact information, and industry. This eliminates the need for developers to manually write extensive code to associate pages with data, thus achieving automatic linkage between the page and the underlying data, improving page building efficiency, and ensuring consistency between the displayed data and the underlying data. The process scheduling module is supported by the Drools rule engine. The process definition structure data is predefined business process-related data defined by the enterprise according to its own business needs, including each node in the business process, the execution requirements of each node, and the pre- and post-dependencies between nodes. Based on the process definition structure data, the pre- and post-dependencies and conditional expressions of each node are parsed. Pre- and post-dependencies are the execution order requirements between different nodes in the process. For example, the "order submission" node must be executed before the "order review" node. This order is a pre- and post-dependency relationship. Conditional expressions are logical statements used to determine the execution path of the process. For example, "When the order amount is greater than 1000 yuan, execute the advanced review node; otherwise, execute the ordinary review node." Such a statement is a conditional expression. It is important to note that the conditional expression here is only used to determine the node execution path and does not involve specific monetary calculations; it is only used as a basis for logical judgment. By parsing this information, the process scheduling module can determine the node topology, that is, organize all nodes in the process according to pre- and post-dependencies into a structured graph, so as to clearly present the relationships and execution order between each node. Based on the data instances generated by the page building module, a unique process instance identifier is assigned to the currently executing business process. The process instance identifier is used to distinguish different business process execution instances. For example, in the same order process, the process execution instances corresponding to orders submitted by different users will have different process instance identifiers, so as to facilitate individual control and traceability of each process execution process. In addition, the process scheduling module sorts the node topology structure, and the node execution sequence is determined according to the specific execution order of each node according to the dependency relationship in the node topology structure, so as to ensure that the process can proceed in an orderly manner.During process execution, when a node containing a conditional expression is encountered, the process scheduling module performs rule matching. Rule matching verifies and judges the conditional expression to determine the subsequent process execution path. When a node requiring access to system resources is encountered—that is, a resource access node—it indicates that the execution requires access to system resources such as data, interfaces, and files. For example, the "view customer historical orders" node requires access to order data resources in the system. At this time, the process scheduling module performs permission matching. Permission matching verifies whether the user or role currently executing the node has the permission to access the resources required by the node. This achieves linkage between the process and the rules. At the same time, permission matching avoids security risks caused by unauthorized access, ensuring the orderly and secure execution of the business process.

[0022] Understandably, the process scheduling module sends relevant data to the rule service module during rule matching. The rule service module receives data from both the page building module and the process scheduling module. The data sent by the page building module mainly consists of rule validation data related to page components, while the data sent by the process scheduling module mainly consists of rule matching parameters corresponding to conditional expressions. The rule service module performs rule matching calculations based on the rule unit version identifier, which distinguishes different versions of rule units. Since enterprise business rules are iteratively updated according to requirements, different versions of rule units correspond to different rule logics. The rule unit version identifier allows for precise invocation of the corresponding rule version, avoiding rule confusion and achieving centralized rule management and version control. It also provides unified rule support for page building and process scheduling, preventing rule logic fragmentation and improving the system's adaptability to complex business rules. The cloud-native runtime module relies on Dockke for packaging and distribution, avoiding deployment failures caused by environmental differences. The cloud-native runtime module encapsulates the metadata modeling module, page building module, process scheduling module, and rule service module, packaging each module into an independent container. Each container contains all the necessary environment and dependencies for module operation. Simultaneously, the cloud-native runtime module integrates a service mesh to enable visualization, observability, and controllability of inter-service communication. Relying on a container orchestration controller, the cloud-native runtime module utilizes Kubernetes' auto-scaling mechanism to deploy, start, stop, scale up, and scale down container instances. Inter-service communication management controls the communication between the container instances corresponding to the four modules, ensuring efficient and stable data and instruction transmission between modules. This avoids the problems of traditional system architectures struggling to support cloud-native environments and achieve elastic scaling. Through containerization and container orchestration, the system achieves elastic deployment and dynamic scheduling, and can flexibly adjust system resources according to changes in business load. This improves system scalability while ensuring the operational stability of digital business operations across multiple business scenarios.

[0023] In some embodiments of this application, parsing the database table structure includes: a metadata modeling module reading database metadata, extracting field names, field types, constraints and foreign key relationships, constructing a set of field attributes based on field names and field types, constructing an entity association mapping table based on foreign key relationships, integrating the set of field attributes and the entity association mapping table, and determining entity description structure data.

[0024] Specifically, database metadata is data used to describe the basic information of a database, such as its structure, field characteristics, and table relationships. It is not the business data generated by the actual business operations of an enterprise, but rather the basic information defining the database table structure; it is equivalent to the database's "instruction manual." The metadata modeling module extracts four types of information from the database metadata: field names, field types, constraints, and foreign key relationships. Constraints are restrictions on the value range and usage rules of each field in the database table structure, used to standardize field usage and ensure the standardization and accuracy of field data. For example, restrictions may include that a field cannot be null, that a field's value must be unique, or that a field has a fixed default value. Foreign key relationships are associations established between different database tables through specific fields, used to enable data linkage between different tables, ensuring that related data in different tables can correspond and be consistent. For example, if the database table structure has an "Order Table" and a "Customer Table," and both the "Order Table" and "Customer Table" have a "Customer ID" field, the association established through this "Customer ID" field is a foreign key relationship. This relationship allows for quick association of order data with the corresponding customer information. The metadata modeling module constructs a field attribute set based on the extracted field names and types. This set, which is a collection of all extracted field names and their corresponding field types, clearly and comprehensively presents the basic attributes of all fields. Based on the extracted foreign key relationships, an entity association mapping table is constructed. This table records the structured relationships between different data entities, clearly indicating the associated entity for each foreign key and the specific association method between entities. The metadata modeling module merges the basic field information recorded in the field attribute set with the entity association information recorded in the entity association mapping table to eliminate redundant information. This ensures that the integrated information contains both complete field attributes and entity associations, ultimately determining the entity description structure data containing entity identifiers, field attributes, and entity associations. This further strengthens the reliability of the entity description structure data as a unified data reference source for the entire system, avoiding data omissions, association errors, and field information confusion caused by non-standard or careless parsing processes. It reduces system development and maintenance costs due to data parsing errors, laying the foundation for efficient and collaborative system operation.

[0025] In some embodiments of this application, determining a data instance includes: a page building module reading a set of field attributes and mapping the set of field attributes to a set of page component types; determining page component parameters based on the field types; establishing a mapping relationship between page component parameters and entity fields; reorganizing business data based on the mapping relationship; and determining a data instance.

[0026] Specifically, after reading the set of field attributes, the page building module maps the set of field attributes to the set of page component types, which are the various component sets pre-set in the system for building business pages. The set of page component types can include different component types such as text input type components, option selection type components, and information display type components. Through the mapping operation, the page building module can match the appropriate page component type for each field. Page component parameters are determined based on field types. These parameters define the display format, interaction rules, and configuration information of the page component's operational characteristics. Different field types correspond to different page component parameters, ensuring that the page component can adapt to the display and usage requirements of the corresponding fields. A mapping relationship is established between page component parameters and entity fields. This mapping relationship is a one-to-one association rule between page component parameters and entity fields. Through the mapping relationship, it is ensured that the page component can accurately connect to the information corresponding to the entity fields. After the mapping relationship is established, the page building module will reorganize the business data based on the mapping relationship. Business data refers to the real business information generated during the actual business operations of the enterprise. Field reorganization is to classify, integrate, and match the relevant field content in the business data according to the corresponding rules determined by the mapping relationship. Through field reorganization, the business data, entity fields, and page components can form a unified corresponding structure, thereby determining the data instance corresponding to the entity identifier. This achieves accurate connection between field attributes, page components, and business data, avoiding the problem of page construction being disconnected from the data model. It eliminates the need for manually writing a large amount of data connection code, thereby improving the adaptation efficiency of business pages and business data, while ensuring the standardization and accuracy of data instances.

[0027] In some embodiments of this application, determining the node execution sequence includes: the process scheduling module reads the node identifier, node type, and node dependency information from the process definition structure data, constructs a node adjacency matrix based on the node dependency information, constructs a directed graph on the node adjacency matrix to determine the node topology, performs a cycle check on the node topology, generates a node sorting list if there is no cycle dependency, binds the data instance to the node sorting list, and determines the process instance identifier and the corresponding node execution sequence.

[0028] Specifically, the process scheduling module obtains node identifiers, node types, and node dependency information from the process definition structure data. Node identifiers are used to distinguish different nodes in the business process. Node types represent the functional categories corresponding to each node in the business process. Node dependency information is the execution constraints and association information between different nodes in the business process. In other words, node dependency information reflects the requirement that a certain node can only start after another node has completed execution. The process scheduling module constructs a node adjacency matrix based on the node dependency information. The node adjacency matrix is ​​a structured carrier that records the adjacent associations and dependencies between each node in the process. It can completely sort out the preceding and following associated nodes of each node. The process scheduling module constructs a directed graph from the node adjacency matrix to determine the node topology. Directed graph construction is to transform the node adjacency matrix into a structural relationship with a clear execution direction according to the dependency directions between nodes. The node topology is a structured layout formed by combining various nodes in the business process according to their dependency relationships. It can intuitively and clearly reflect the execution direction and relationships of the process nodes. The loop detection checks whether there are closed-loop dependencies between nodes in the node topology and whether the execution order cannot be determined. The loop detection can identify loop conflicts where one node depends on another node for execution, and the other node in turn depends on the first node for execution. If the detection result is that there are no loop dependencies, the process scheduling module generates a node sorting list. The node sorting list is a list of nodes with a fixed order obtained according to the dependency relationship of the node topology. The data instance is bound to the node sorting list, that is, the data instance corresponding to the business is associated with the sorted node sorting list, so that the execution of the node sorting list can accurately match the corresponding data instance, thereby determining the process instance identifier and the corresponding node execution sequence. The process instance identifier is used to uniquely identify the execution process of this business process, and the node execution sequence represents the execution order of nodes corresponding to the process instance identifier and is directly used for the actual execution of the business process.

[0029] Understandably, by reading and sorting out node dependency information, constructing a node adjacency matrix, transforming a directed graph, and performing loop detection, the stability of the node execution order in the business process is ensured, avoiding problems such as node execution chaos and process stagnation during process execution. At the same time, binding data instances with the node sorting list achieves a precise correspondence between process execution logic and business data, improving the stability, accuracy, and intelligence of business process execution.

[0030] It should be noted that the node adjacency matrix and directed graph construction in this application can be implemented using existing technologies in the field, and are not the focus of the improvements claimed in this application. The focus of the improvements in this application lies in the process organization method, data connection relationship, and constraint processing logic in the node execution sequence. Taking the process definition structure data as input and outputting the process instance identifier and the corresponding node execution sequence, those skilled in the art can complete the adaptation, replacement, or equivalent implementation based on the input-output relationship, parameter configuration rules, and calling sequence disclosed in this application, combined with existing disclosed technologies or conventional engineering methods, without affecting the implementation of the technical solution of this application.

[0031] In some embodiments of this application, when executing a node containing a conditional expression, the process includes: a process scheduling module determining rule matching parameters based on the conditional expression and sending the rule matching parameters to a rule service module; the rule service module loading the corresponding rule version based on the rule unit version identifier and performing a conditional comparison operation on the rule matching parameters; returning a node path identifier based on the comparison result; and the process scheduling module updating the node execution sequence based on the node path identifier.

[0032] Specifically, the process scheduling module determines rule matching parameters based on conditional expressions. These parameters are the information needed for rule comparison; they are key content extracted from the conditional expressions to match corresponding business rules. For example, when a conditional expression is used to determine the processing branch of a business process, the rule matching parameters are the feature information used to distinguish the different branch paths. The process scheduling module sends the determined rule matching parameters to the rule service module. Upon receiving the parameters, the module loads the corresponding rule version based on the rule unit version identifier. This identifier uniquely distinguishes different iteration versions of rule units, with different identifiers corresponding to rule content in different business stages or scenarios. The rule version corresponds to the specific business rule logic content associated with the identifier. For instance, when enterprise business rules are updated and optimized, new rule versions are generated. The rule unit version identifier allows for precise invocation of the corresponding rule version, preventing rule misuse or confusion. The conditional comparison operation on the rule matching parameters involves checking each parameter against the rule logic in the loaded rule version to determine if it meets the requirements of the corresponding rule. The rule service module returns a node path identifier based on the comparison result. This identifier uniquely distinguishes different execution paths in the business process; different comparison results correspond to different node path identifiers, guiding the business process to the appropriate execution branch. Upon receiving the node path identifier, the process scheduling module updates the node execution sequence. This update adjusts or replaces the original node execution sequence based on the corresponding execution branch, ensuring it meets the actual execution requirements of the business process after the conditional comparison. This enables the process scheduling module and the rule service module to work together, ensuring the accuracy and iterative nature of business rule usage. This improves the intelligence and flexibility of business process execution and enhances the system's adaptability to complex and ever-changing business rules.

[0033] In some embodiments of this application, when executing a node for resource access, the process includes: the process scheduling module extracts the identity identifier and the resource identifier, reads the permission set data based on the identity identifier, and performs a matching operation between the permission set data and the resource identifier. When the matching result is "access allowed", a node execution flag is generated; when the matching result is "access denied", a node termination flag is generated; and the node execution flag or node termination flag is written into the status record corresponding to the process instance identifier.

[0034] In some embodiments of this application, when writing the status record corresponding to the process instance identifier, the process includes: the process scheduling module reads the rule matching result and the permission matching result, generates data parameters containing node identifier, execution timestamp and node execution, and numbers the data parameters according to the node execution order to determine the node execution sequence record dataset, and integrates the node execution sequence record dataset based on the process instance identifier to determine the execution trajectory data chain.

[0035] Specifically, the identity identifier is a unique identifier that identifies the operator, while the resource identifier is used to uniquely distinguish different resources to be accessed within the system. The operator can be a user of the system or an external system being integrated. The resource to be accessed can be business data, system function interfaces, or file content. The process scheduling module reads the corresponding permission set data based on the extracted identity identifier. The permission set data contains information related to all resources that are bound to that identity identifier and that the operator has the necessary operation or access permissions. The process scheduling module then performs a matching operation between the read permission set data and the resource identifier, that is, it verifies and checks the resource identifier to be accessed against the permission information in the permission set data to determine whether the current operator is qualified to access the corresponding resource. If the matching operation results in "access allowed," the process scheduling module generates a node execution flag, allowing the current node to continue normal execution. If the matching operation results in "access denied," the process scheduling module generates a node termination flag, prohibiting the current node from continuing execution and terminating the process. The process scheduling module writes the generated node execution flag or node termination flag into the status record corresponding to the process instance identifier. The status record is an information carrier that records various running states and verification results of the corresponding process instance during execution. When performing the operation of writing the status record corresponding to the process instance identifier, the process scheduling module will simultaneously read the rule matching results obtained from the previously executed conditional expression node and the permission matching results obtained from the executed resource access node. The matching result is the rule verification result obtained by the rule service module after condition comparison calculation. The permission matching result is the resource access verification result obtained by the process scheduling module after permission matching calculation. The process scheduling module generates data parameters containing node identifiers, execution timestamps, and node execution data. The execution timestamp records the time node information when the node execution or verification operation occurs. The node execution data parameters record information about the node execution process, verification results, and running status. The process scheduling module numbers the generated data parameters according to the actual execution order of the nodes to determine the node execution sequence record dataset. The node execution sequence record dataset is a collection of information containing details of each node's execution, organized according to the execution order. The process scheduling module is based on... The process instance identifier unifies and integrates the node execution sequence record dataset, summarizing the execution records of all nodes under the same process instance into a complete information chain, and finally determining the execution trajectory data chain. The execution trajectory data chain is a complete traceability information chain that records the execution order, verification results, running status, and time nodes of all nodes in the corresponding process instance from startup to execution. Through the matching and calculation of identity identifiers, resource identifiers, and permission set data, it realizes fine-grained and dynamic permission control of resource access, avoids data security risks caused by unauthorized access, and realizes complete recording and traceability of the entire business process execution process. It not only ensures the security and standardization of process execution, but also improves the system's management capabilities and operational efficiency.

[0036] In some embodiments of this application, the digital business operating system supporting multiple business scenarios further includes: a cloud-native runtime module that obtains the process instance identifier and the corresponding execution trajectory data chain, encapsulates the execution trajectory data chain to determine the runtime data object, and performs container instance mapping on the runtime data object.

[0037] Specifically, the cloud-native runtime module relies on Docke for packaging and distribution. It encapsulates the acquired execution trajectory data chain, transforming the originally scattered process execution records into a standardized, unified data format that is easy for system transmission, storage, and retrieval. This is analogous to organizing fragmented information recording the entire process into a complete and standardized file according to fixed specifications, making it more adaptable to the processing rules of the cloud-native environment. The runtime data object is a business runtime data carrier that, after structural encapsulation, fully carries the execution trajectory information and possesses an independent and unified structure. It can completely correspond to and store all execution process information of a single process instance. The cloud-native runtime module performs container instance mapping on the completed runtime data objects, establishing a precise and unique correspondence between the runtime data objects and the container instances running in the cloud-native environment, ensuring that each runtime data object... All objects are assigned to specific container instances to achieve a stable binding between business operation data and the container runtime. Container instance mapping is like assigning a dedicated runtime management carrier to each packaged process operation data, thereby ensuring the correspondence between data and containers. It transforms business execution data into a data format adapted to the cloud-native architecture, ensuring the stability and standardization of execution trajectory data in the cloud-native environment for processing, transmission, and storage. At the same time, container instance mapping achieves precise binding between runtime data and container instances, making it easier for the cloud-native runtime module to independently distinguish, classify, manage, and schedule the runtime data of different process instances. This avoids cross-contamination and confusion of runtime data from different process instances, providing a precise data foundation for the cloud-native runtime module to perform subsequent operations such as status monitoring and resource allocation of container instances, further enhancing the system's adaptability to the cloud-native environment.

[0038] In some embodiments of this application, when mapping a runtime data object to a container instance, the process includes: a cloud-native runtime module reading the runtime status data of the corresponding container, the runtime status data including the instance number, load parameters and resource allocation parameters, associating and storing the load parameters and process instance identifier, and determining instance scheduling record data.

[0039] In some embodiments of this application, when mapping container instances to runtime data objects, the method further includes: the cloud-native runtime module adjusting the number of container replicas based on the container orchestration controller, generating replica expansion instructions or replica reduction instructions based on the adjustment results, and reallocating the mapping relationship between containers and process instance identifiers.

[0040] Specifically, the cloud-native runtime module reads the runtime status data of the corresponding container. This data reflects the container's operational status, load status, and resource usage during runtime in the cloud-native environment. The runtime status data includes the instance ID, load parameters, and resource allocation parameters. The instance ID distinguishes different container instances within the cloud-native environment. Load parameters reflect the current business processing pressure and runtime load of the container instance. Resource allocation parameters represent the configuration parameters of the computing, storage, and network resources allocated to the corresponding container instance by the cloud-native environment. The cloud-native runtime module associates and stores the load parameters and process instance identifiers, establishing a binding relationship between the container instance's load parameters and the corresponding process instance identifier and saving them uniformly. This allows the system to quickly query the load status of the corresponding container instance using the process instance identifier. It can also locate the corresponding process instance through load parameters, and then determine the instance scheduling record data. The instance scheduling record data is scheduling-related data that records the container instance running status, load, process instance correspondence, and resource allocation. When mapping the running data object to a container instance, the container orchestration controller integrates Kubernetes orchestration capabilities and microservice architecture to uniformly manage the creation, destruction, scheduling, allocation, and scaling of container instances. The number of container replicas is the total number of container instances corresponding to the same service in the cloud-native environment. The cloud-native runtime module generates replica expansion instructions or replica reduction instructions based on the adjustment result of the number of container replicas. That is, after adjusting the load, the container is scaled up or down. The replica expansion instruction is the control instruction to increase the number of container replicas, and the replica reduction instruction is the control instruction to decrease the number of container replicas. After executing replica expansion or reduction instructions, the cloud-native runtime module reallocates the mapping relationship between containers and process instance identifiers. Based on the adjustment of the number of container replicas, it re-establishes the corresponding association between process instance identifiers and the adjusted container instances, ensuring that each process instance is matched with a resource-adapted and stable container instance. By reading container runtime status data and associating storage load parameters with process instance identifiers, it forms complete instance scheduling record data, realizing real-time monitoring, unified management, and full traceability of the correspondence between container instance runtime status and process instance. At the same time, the container orchestration controller dynamically adjusts the number of container replicas, generates corresponding replica expansion or reduction instructions, and reallocates the mapping relationship, realizing elastic allocation and load balancing of system resources. The system can flexibly add or remove container instances according to changes in actual business load, avoiding the problems of business process execution lag and interruption caused by insufficient container resources, and also avoiding the resource waste caused by idle container resources. This improves the system's resource utilization, operational stability, and carrying capacity in multi-business scenarios, thereby strengthening the system's adaptability and support capabilities for multi-business scenarios.

[0041] In summary, the beneficial effects of this invention are as follows: Parsing the database table structure and generating entity description structure data as a unified data reference source avoids the problems of chaotic data sources and heterogeneous data between modules in traditional systems, reducing the amount of customized code development, thereby shortening the development cycle and reducing upgrade and maintenance costs. Based on the entity description structure data, it achieves the mapping between page component fields and entity fields, generating corresponding data instances without the need for manual writing of association code, thus improving the efficiency of building business pages. Based on node execution sequence sorting, rule matching processing, and permission matching processing, it achieves deep linkage between process orchestration and rule logic, improving the problem of fragmented business logic configuration. Furthermore, through refined permission matching, it meets the dynamic management needs of multiple business entities, multiple resource types, and multiple operational dimensions. It completes rule matching calculations based on rule unit version identifiers, realizing centralized management of rule logic and building a full-link development capability integrating data, pages, processes, and rules. At the same time, by encapsulating and relying on the container orchestration controller to complete instance deployment, scheduling, and inter-service communication management, the system has containerized deployment capabilities, breaking away from the limitations of monolithic architecture and traditional distributed architecture. This improves the system's performance stability and scalability in multiple business scenarios, while also taking into account development efficiency, thereby meeting the development requirements of enterprise full-stack business systems.

[0042] This application is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program goods according to embodiments of this application. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart... Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0043] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention and not to limit it. Although the present invention has been described in detail with reference to the above embodiments, those skilled in the art should understand that modifications or equivalent substitutions can still be made to the specific implementation of the present invention. Any modifications or equivalent substitutions that do not depart from the spirit and scope of the present invention should be covered within the scope of protection of the claims of the present invention.

Claims

1. A digital business operating system supporting multiple business scenarios, characterized in that, include: The metadata modeling module is configured to parse the database table structure, generate entity description structure data containing entity identifiers, field attributes, and entity relationships, and use the entity description structure data as a unified data reference source. The page building module is configured to determine page structure definition data based on the entity description structure data, and determine the mapping relationship based on page component fields and entity fields. After receiving business data, it determines the data instance corresponding to the entity identifier based on the mapping relationship. The process scheduling module is configured to parse the pre- and post-dependent relationships and conditional expressions based on the process definition structure data, determine the node topology, determine the process instance identifier based on the data instance, sort the node topology to determine the node execution sequence, perform rule matching processing when executing a node containing the conditional expression, and perform permission matching processing when executing a node accessing resources. The rules service module is configured to receive data from the page building module and the process scheduling module, and perform rule matching calculations based on the rule unit version identifier; The cloud-native runtime module is configured to encapsulate the metadata modeling module, page building module, process scheduling module, and rule service module, and to perform instance deployment, scheduling, and inter-service communication management based on the container orchestration controller.

2. The digital business operating system supporting multiple business scenarios according to claim 1, characterized in that, When parsing the database table structure, the process includes: the metadata modeling module reading the database metadata, extracting field names, field types, constraints and foreign key relationships, constructing a set of field attributes based on the field names and field types, constructing an entity association mapping table based on the foreign key relationships, integrating the set of field attributes and the entity association mapping table, and determining the entity description structure data.

3. The digital business operating system supporting multiple business scenarios according to claim 2, characterized in that, When determining a data instance, the process includes: the page building module reading the field attribute set and mapping the field attribute set to the page component type set; determining page component parameters based on the field types; establishing a mapping relationship between the page component parameters and entity fields; and reorganizing the business data based on the mapping relationship to determine the data instance.

4. The digital business operating system supporting multiple business scenarios according to claim 3, characterized in that, When determining the node execution sequence, the process includes: the process scheduling module reads the node identifier, node type, and node dependency information from the process definition structure data, constructs a node adjacency matrix based on the node dependency information, constructs a directed graph on the node adjacency matrix to determine the node topology, performs a cycle check on the node topology, generates a node sorting list if no cycle dependency exists, and binds the data instance to the node sorting list to determine the process instance identifier and the corresponding node execution sequence.

5. The digital business operating system supporting multiple business scenarios according to claim 4, characterized in that, When executing a node containing the conditional expression, the process includes: the process scheduling module determining rule matching parameters based on the conditional expression and sending the rule matching parameters to the rule service module; the rule service module loading the corresponding rule version based on the rule unit version identifier and performing a conditional comparison operation on the rule matching parameters; returning a node path identifier based on the comparison result; and the process scheduling module updating the node execution sequence based on the node path identifier.

6. The digital business operating system supporting multiple business scenarios according to claim 5, characterized in that, When executing a node for resource access, the process includes: the process scheduling module extracting the identity identifier and the resource identifier, reading the permission set data based on the identity identifier, and performing a matching operation between the permission set data and the resource identifier. When the matching result is "access allowed", a node execution flag is generated; when the matching result is "access denied", a node termination flag is generated. The node execution flag or node termination flag is then written into the status record corresponding to the process instance identifier.

7. The digital business operating system supporting multiple business scenarios according to claim 6, characterized in that, When writing the status record corresponding to the process instance identifier, the process scheduling module reads the rule matching result and the permission matching result, generates data parameters containing node identifier, execution timestamp and node execution, and numbers the data parameters according to the node execution order to determine the node execution sequence record dataset. Based on the process instance identifier, the node execution sequence record dataset is integrated to determine the execution trajectory data chain.

8. The digital business operating system supporting multiple business scenarios according to claim 7, characterized in that, Also includes: The cloud-native runtime module obtains the process instance identifier and the corresponding execution trajectory data chain, encapsulates the execution trajectory data chain to determine the runtime data object, and maps the runtime data object to a container instance.

9. The digital business operating system supporting multiple business scenarios according to claim 8, characterized in that, When mapping the runtime data object to a container instance, the process includes: the cloud-native runtime module reading the runtime status data of the corresponding container, the runtime status data including the instance number, load parameters and resource allocation parameters, associating and storing the load parameters and process instance identifier, and determining the instance scheduling record data.

10. The digital business operating system supporting multiple business scenarios according to claim 9, characterized in that, When mapping the runtime data object to a container instance, the cloud-native runtime module adjusts the number of container replicas based on the container orchestration controller, generates replica expansion instructions or replica reduction instructions based on the adjustment results, and reallocates the mapping relationship between the container and the process instance identifier.

Images