An event hub-based data sink system and event processing method

Abstract

The application discloses a data base system based on an event hub and an event processing method, and relates to the technical field of computer data processing. The system comprises a heterogeneous system interaction module which is connected to an external system under the verification and authorization of an authentication center, acquires multi-source initial data and transmits the data to an event hub, and also receives and sends standardized data; the event hub calls the dynamically configurable business logic of a code center, processes the multi-source initial data into standardized data, and performs directional distribution; the code center is a pluggable and dynamically loaded business logic management center, the dynamically configurable business logic of the code center comprises various forms such as low-code configuration, script code, rule set and built-in algorithm, and the code center opens an interface to the event hub after authentication; a process engine receives the standardized data and triggers an approval process; and a data center stores data and provides a query interface. The system can improve the problems of heterogeneous system integration difficulty and data island, improve data processing efficiency, reduce customization cost, and enhance data security.

Description

Technical Field

[0001] This invention relates to the field of computer data processing technology, and in particular to a data foundation system and event processing method based on an event hub. Background Technology

[0002] In the process of information technology development, organizations need to integrate increasingly diverse types of systems, including new business software and IoT devices with standard interfaces, as well as a large number of traditional, outdated systems lacking external system APIs. These heterogeneous systems, due to differences in technical architecture, data formats, and interface specifications, create barriers to data flow.

[0003] In existing technologies, integrating such heterogeneous systems often faces the challenge of unified access: for systems with interfaces, customized interfaces need to be developed for data interaction, resulting in high costs and poor scalability; for traditional legacy systems without interfaces, there is a lack of effective data acquisition and write-back methods, leading to the long-term existence of data silos. Simultaneously, the flow of data between systems lacks a unified processing logic, making it difficult to automate business processes, and the fragmented access control between systems hinders secure data interaction management, ultimately resulting in low data processing efficiency, slow business response, and an inability to meet the organization's needs for efficient data integration and automated business processing. Summary of the Invention

[0004] To address the technical problems in the prior art, this invention provides a data foundation system and event processing method based on an event hub.

[0005] The technical solution adopted in this invention is:

[0006] The first aspect of this application provides a data foundation system based on an event hub, the data foundation including multiple modular components, the multiple modular components including a heterogeneous system interaction module, an event hub, a code center, a process engine, a data center and an authentication center;

[0007] Under the authentication and authorization of the authentication center, the heterogeneous system interaction module is used to interact with external systems to obtain multi-source initial event data and output the multi-source initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and distribute the standardized event data to external systems.

[0008] Under the authentication and authorization of the authentication center, the event hub is used to receive multi-source initial event data output by the heterogeneous system interaction module, call the dynamically configurable business logic stored in the code center to clean, process and verify the multi-source initial event data, generate standardized event data, determine the distribution path of the standardized event data based on the distribution conditions included in the dynamically configurable business logic, and distribute the standardized event data to the process engine, data center and heterogeneous system interaction module according to the distribution path.

[0009] The code center is used to store dynamically configurable business logic; wherein, the dynamically configurable business logic includes data processing rules and distribution conditions, and after the authentication center verifies the calling permission of the event hub, the code center opens the calling interface of the dynamically configurable business logic to the event hub.

[0010] Under the authentication and authorization of the authentication center, the process engine is used to receive standardized event data distributed by the event hub, trigger and execute business approval processes;

[0011] Under the authentication and authorization of the authentication center, the data center is used to receive standardized event data distributed by the event hub and perform persistent storage, and to open a standard query interface with multiple parameter combinations to components that have been authenticated by the authentication center.

[0012] Preferably, the heterogeneous system interaction module includes an interface center and an AI center, and the multi-source initial event data includes first initial event data, second initial event data, and third initial event data.

[0013] Under the authentication and authorization of the authentication center, the interface center is used to receive first initial event data pushed by external systems, or actively capture second initial event data from external systems, and output the first initial event data or the second initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and push the standardized event data to the external systems that provide the interface;

[0014] The AI ​​center integrates a user interface automated interaction tool, which, under the authentication and authorization of the authentication center, is used to crawl third-party multi-source initial event data from external systems without interfaces and output the third-party multi-source initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and write the standardized event data back to the external systems without interfaces through the user interface automated interaction tool.

[0015] Preferably, it also includes a task center; the task center, under the authentication and authorization of the authentication center, is used to schedule the interface center to actively crawl the second initial event data from the external system that provides the interface, and to schedule the AI ​​center to crawl the third initial event data from the external system without the interface.

[0016] Preferably, it also includes a BI center, which, under the authentication and authorization of the authentication center, is used to call the standard query interface of the data center to obtain standardized event data, perform statistical analysis, and generate serialized statistical data.

[0017] Preferably, it also includes a notification center; the notification center, under the authentication and authorization of the authentication center, is used to receive calls from heterogeneous system interaction modules, event hubs, code centers, process engines, data centers and BI centers; and to determine the specified relevant parties based on the notification object identifier in the call information.

[0018] Preferably, the process engine is also used to interact with lower-level process engines; under the authentication and authorization of the authentication center, the process engine dispatches process events to the lower-level process engines; under the authentication and authorization of the authentication center, the lower-level process engines receive and process the process events, and report the processing results and real-time processing status of the process events to the external system of the process engine.

[0019] Preferably, the dynamically configurable business logic stored in the code center supports user-defined configuration; users can modify data processing rules and distribution conditions through the visual configuration interface provided by the code center. The modified dynamically configurable business logic takes effect after the authentication center verifies the user's operation permissions and is synchronized to the event hub's call interface.

[0020] A second aspect of this application provides an event processing method for an event-centric data infrastructure system, applied to the aforementioned event-centric data infrastructure system, comprising the following steps:

[0021] Step 1: Under the authentication and authorization of the authentication center, the heterogeneous system interaction module interacts with the external system to obtain multi-source initial event data and transmits the multi-source initial event data to the event hub.

[0022] Step 2: Under the authentication and authorization of the authentication center, the event hub calls the dynamically configurable business logic stored in the code center to clean, process and verify the multi-source initial event data obtained in Step 1, and generate standardized event data.

[0023] Step 3: Based on the distribution conditions included in the dynamically configurable business logic, the event hub determines the distribution path of the standardized event data generated in Step 2, and distributes the standardized event data to at least one component of the process engine, data center, and heterogeneous system interaction module; if the event hub distributes the standardized event data to the process engine, then proceed to Step 4; if the event hub distributes the standardized event data to the data center, then proceed to Step 5; if the event hub distributes the standardized event data to the heterogeneous system interaction module, then proceed to Step 6.

[0024] Step 4: Under the authentication and authorization of the authentication center, the process engine receives the standardized event data distributed in Step 3, triggers and executes the business approval process;

[0025] Step 5: Under the authentication and authorization of the authentication center, the data center receives the standardized event data distributed in Step 3, performs persistent storage, and opens a standard query interface with multiple parameter combinations to components that have been authenticated by the authentication center.

[0026] Step 6: Under the authentication and authorization of the authentication center, the heterogeneous system interaction module receives the standardized event data distributed in Step 3 and distributes it to external systems.

[0027] The beneficial effects of the present invention are at least one of the following:

[0028] The heterogeneous system interaction module can uniformly connect to multiple types of external systems, which helps reduce the need for customized development for systems with different interface types, improves the data access difficulties of legacy systems without interfaces, and alleviates the problem of data silos.

[0029] The event hub processes data by calling dynamically configurable business logic from the code center, which can improve the uniformity of multi-source data processing logic, reduce processing costs caused by differences in data formats, and improve the lack of standards in data flow.

[0030] The process engine and event hub work together to enable business approval processes to be automatically triggered based on standardized data, which helps to promote the automation of business processes and reduce delays caused by manual intervention.

[0031] The unified verification and control of interactions between various components by the certification center can improve the problem of fragmented permission management and enhance the security of data in the stages of collection, processing and distribution.

[0032] Through the collaborative operation of data collection, standardized processing, targeted distribution, process linkage, and security control, the various components help to improve overall data processing efficiency, enhance business response speed, and support the organization's efficient data integration and automated processing. Attached Figure Description

[0033] Figure 1 This is a system structure block diagram of the present invention;

[0034] Figure 2 This is a schematic diagram of the method flow of the present invention. Detailed Implementation

[0035] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.

[0036] Example 1 provides a data foundation system based on an event hub, such as Figure 1 As shown, the data base includes multiple modular components, including a heterogeneous system interaction module, an event hub, a code center, a process engine, a data center, and an authentication center.

[0037] Under the authentication and authorization of the authentication center, the heterogeneous system interaction module is used to interact with external systems to obtain multi-source initial event data and output the multi-source initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and distribute the standardized event data to external systems.

[0038] It should be noted that external systems exhibit significant heterogeneity due to differences in technical architecture, development era, and interface specifications (e.g., newer systems have standard APIs, while older systems lack interfaces), making it difficult to unify data access and flow, thus creating data silos.

[0039] To address this issue, the heterogeneous system interaction module is a core functional module used to uniformly connect with various external systems (including systems with interfaces, without interfaces, and with different technical architectures / data formats) and realize bidirectional data flow. The heterogeneous system interaction module is a data interaction bridge between external systems and the internal systems (event hubs, etc.).

[0040] Multi-source initial event data refers to raw event data obtained from multiple different external systems that has not undergone standardization processing. Standardized event data refers to event data that has been processed by the event hub and conforms to a unified format, field specifications, and validation rules, and can be universally transferred between various components within the system. External systems refer to business systems outside of this data base system that require data interaction (such as enterprise ERP systems, hospital HIS systems, IoT device terminals, traditional legacy business software, etc.).

[0041] Under the authentication and authorization of the authentication center, the heterogeneous system interaction module means that the authentication center verifies the identity and legitimacy of the heterogeneous system interaction module through preset policies (such as account password and key), and grants it specific permissions to interact with external systems and transmit data according to the permission matrix, so as to ensure the security of interaction.

[0042] In the specific implementation process, after the heterogeneous system interaction module is authenticated and authorized by the authentication center, it establishes a connection with various external systems, obtains multi-source initial event data in different ways according to the type of external system (with interface / without interface), and packages and transmits it to the event hub.

[0043] The heterogeneous system interaction module receives standardized event data transmitted from the event hub, verifies the permissions again through the authentication center, and pushes the standardized data to the target external system in an adapted manner according to the interface capabilities of the external system (with or without an interface).

[0044] Specifically, in one possible implementation, such as Figure 1 As shown, the heterogeneous system interaction module includes an interface center and an AI center, and the multi-source initial event data includes first initial event data, second initial event data, and third initial event data.

[0045] Under the authentication and authorization of the authentication center, the interface center is used to receive first initial event data pushed by external systems, or actively capture second initial event data from external systems, and output the first initial event data or the second initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and push the standardized event data to the external systems that provide the interface.

[0046] It should be noted that the Interface Center is a submodule of the Heterogeneous System Interaction Module, specifically designed to interface with external systems that have standard interfaces (such as systems providing API interfaces) to implement data collection and distribution functions. The first initial event data refers to raw event data actively pushed to the Interface Center by the external system with the interface. The second initial event data refers to raw event data actively retrieved by the Interface Center from the external system with the interface. External systems providing interfaces refer to external systems with standard data interaction interfaces (such as HTTP APIs, database interfaces) that support data push or being actively retrieved (such as enterprise CRM systems, government service platforms).

[0047] Specifically, while external systems with interfaces possess data exchange capabilities, their interface specifications and data formats may differ. Directly interfacing with internal system components would require repetitive development of adaptation logic. The interface center, acting as a dedicated interface layer, handles data input and output through unified interface adaptation logic, reducing redundant development and improving the access efficiency of systems with interfaces.

[0048] In the specific implementation process, the interface center connects to systems with standard interfaces (such as the hospital's HIS system), receives the first initial event data pushed (such as real-time registration information), or actively captures the second initial event data (such as daily hospitalization statistics) according to the schedule.

[0049] The AI ​​center integrates a user interface automated interaction tool, which, under the authentication and authorization of the authentication center, is used to crawl third-party multi-source initial event data from external systems without interfaces and output the third-party multi-source initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and write the standardized event data back to the external systems without interfaces through the user interface automated interaction tool.

[0050] It's important to note that the AI ​​Center is a submodule of the Heterogeneous System Interaction Module. It's specifically designed to interface with external systems lacking standard interfaces (such as legacy business software or pure desktop applications), enabling data interaction through automated user interface tools. These automated user interface tools simulate manual operations (such as mouse clicks, keyboard input, and page data extraction), automatically performing data crawling and data entry operations (such as simulating system login and copying / pasting data) on systems without interfaces. These tools can be Robotic Process Automation (RPA) tools, built-in algorithms, script-driven systems, image recognition-based automation scripts, dedicated desktop application driver libraries, etc.

[0051] The third initial event data refers to the raw event data crawled from external systems without interfaces by the AI ​​center through user interface automated interaction tools, which execute preset automated tasks (the automated tasks can be defined and configured in various forms such as low-code, rule sets, or script code).

[0052] Specifically, external systems without interfaces (especially older systems) cannot be connected through conventional interfaces due to technical limitations, making it difficult to incorporate data into the system flow and creating "data silos." The AI ​​Center uses user interface automated interaction tools to simulate manual operation, breaking through interface limitations to enable data "in" (crawl) and "out" (write back), thus solving the data interaction problem of older systems.

[0053] In the specific implementation process, the AI ​​center connects to interface-less systems (such as paper medical record registration systems) through user interface automated interaction tools, crawls third initial event data (such as manually entered examination results), and writes back standardized data (such as approval results).

[0054] Under the authentication and authorization of the authentication center, the event hub is used to receive multi-source initial event data output by the heterogeneous system interaction module, call the dynamically configurable business logic stored in the code center to clean, process and verify the multi-source initial event data, generate standardized event data, determine the distribution path of the standardized event data based on the distribution conditions included in the dynamically configurable business logic, and distribute the standardized event data to the process engine, data center and heterogeneous system interaction module according to the distribution path.

[0055] It should be noted that the event hub is the core data processing and distribution node of the system's data foundation. It is responsible for receiving initial event data from multiple sources, performing standardized processing, and distributing it to relevant components. It is the central unit connecting heterogeneous system interaction modules with process engines, data centers, etc.

[0056] Multi-source initial event data refers to raw event data collected from multiple external systems by heterogeneous system interaction modules, which has not undergone unified processing. Due to different sources, it may have issues such as inconsistent formats, redundant or missing fields, and data errors. Dynamically configurable business logic refers to a set of data processing and distribution rules stored in the code center that can be generated through visual configuration. Data cleaning, processing, validation, and distribution logic can be defined without extensive code development. Cleaning refers to the standardization processing of multi-source initial event data, including removing duplicate data, correcting format errors (such as unifying date formats), and supplementing missing required fields. Processing refers to the transformation or enhancement of the cleaned data, including field mapping (such as associating "User ID" with "Name" to generate "Full User Name"), data aggregation, and business rule calculation. Validation refers to verifying the legality and integrity of the data according to preset rules, including format validation, business logic validation, and permission validation (such as anonymizing sensitive fields like "ID Number").

[0057] Distribution conditions refer to the rules defined in dynamically configurable business logic that determine the destination of standardized event data (such as "events with an order amount > 1000 yuan need to be distributed to the process engine for approval" and "all order events need to be stored in the data center").

[0058] The distribution path refers to the set of standardized event data destinations determined according to the distribution conditions. It typically includes the process engine (triggering approval), data center (storage), heterogeneous system interaction module (returning to external systems), etc.

[0059] Specifically, multi-source initial event data suffers from issues such as format confusion and low data quality due to heterogeneous sources. Directly using it in business processes or storage can lead to process anomalies and difficulties in data reuse. The Event Hub, acting as a "data processing hub," standardizes data by invoking unified, dynamically configurable business logic, thus resolving the heterogeneity problem of multi-source data. Simultaneously, it distributes data in a targeted manner based on preset distribution conditions, ensuring that data flows to the corresponding components according to business needs, providing a reliable foundation for subsequent process automation and data storage reuse.

[0060] In the specific implementation process, after the event center is authenticated and authorized by the authentication center, it receives multi-source initial event data (such as "patient basic information" from the outpatient registration system, "bed application record" from the inpatient department, and "specimen receipt information" from the laboratory) transmitted by the heterogeneous system interaction module, performs integrity verification on the data (such as checking whether it contains mandatory identifiers such as "medical record number"), and rejects incomplete data.

[0061] The event hub initiates a call request to the code center. After the code center verifies the event hub's permissions, it opens the call interface for dynamically configurable business logic. The event hub obtains this logic (including data processing rules and distribution conditions); according to the cleaning rules in the code center's logic, it removes duplicate data (e.g., deduplication based on "medical record number + visit date"), corrects format errors, and supplements missing fields (e.g., automatically filling in "Emergency Department" for emergency records where "Visit Department" is empty); according to the processing rules, it transforms or enhances the data, such as mapping "examination item code" to "examination item name" and calculating "total hospitalization cost = daily cumulative cost"; according to the validation rules, it validates the data, such as checking whether "number of days of hospitalization" is a reasonable value (0-365 days), marking data that does not conform to the rules as "abnormal" and recording the original data. Because (e.g., "the number of days of hospitalization is negative, which may be due to an input error"), the processed data stream is converted into a system-unified format (e.g., JSON structure), containing fixed attributes such as "event type = visit", "processing status = standardized", and "standardized field set = {medical record number, name, department of visit, cost amount}". The distribution conditions in the code center logic are parsed to determine the destination of the standardized event data (e.g., "events with hospitalization costs > 50,000 yuan need to be distributed to the process engine for approval" and "all visit events need to be distributed to the data center for storage and simultaneously sent back to the medical insurance settlement system"). The standardized event data is then transmitted to the process engine, data center, and heterogeneous system interaction module according to the distribution path, and the distribution log is recorded (including distribution time, receiving component, data identifier = medical record number).

[0062] The code center is used to store dynamically configurable business logic; wherein, the dynamically configurable business logic includes data processing rules and distribution conditions, and after the authentication center verifies the calling permission of the event hub, the code center opens the calling interface of the dynamically configurable business logic to the event hub.

[0063] In one possible implementation, the dynamically configurable business logic stored in the code center supports user-defined configuration; users modify data processing rules and distribution conditions through the visual configuration interface provided by the code center, and the modified dynamically configurable business logic takes effect after the authentication center verifies the user's operation permissions and is synchronized to the event hub's call interface.

[0064] It should be noted that the code center refers to the functional module in the data foundation of this system used for centralized storage and management of dynamically configurable business logic. It is the core data source for the event hub to obtain data processing and distribution rules, and has the capabilities of logical storage, access control and interface opening.

[0065] Dynamically configurable business logic refers to a set of data processing and distribution rules that can be defined through a visual interface (such as drag-and-drop components or configuration parameters) without the need for traditional code writing (or with only a small amount of code). It supports users in flexibly modifying the rules according to their business needs and includes two parts: data processing rules and distribution conditions.

[0066] Data processing rules refer to the specific rules in dynamically configurable business logic used to standardize the processing of multi-source initial event data, including cleaning rules (such as format standardization), processing rules (such as field calculation), and validation rules (such as legality verification), etc. (e.g., "keep 2 decimal places for the 'amount' field" and "remove records with empty 'user ID'").

[0067] Distribution conditions refer to the rules in dynamically configurable business logic used to determine the destination of standardized event data flow, defining which components (such as process engine and data center) the data should be distributed to and the triggering conditions (e.g., "order amount > 5000 yuan should be distributed to process engine" or "all events should be distributed to data center").

[0068] The API refers to the technical interface (such as an API interface) provided by the code center to the event hub for obtaining dynamically configurable business logic. The event hub calls the required logic through this interface, which is only opened after the permission verification is passed.

[0069] After the code center verifies the event hub's calling permissions in the certification center, it means that the certification center verifies whether the event hub has the permission to call specific dynamically configurable business logic in the code center according to the preset permission matrix (such as only allowing the event hub to call "order" logic and not allowing it to call "financial" logic). Only after the verification is passed can the interface be opened.

[0070] Specifically, in traditional data processing systems, data processing logic and distribution rules are typically embedded in the code. Modifications require developer intervention, resulting in long lead times, low flexibility, and fragmented management of logic across multiple components, which can easily lead to inconsistencies. The code center, by centrally storing dynamically configurable business logic, decouples data processing and distribution rules from hard-coded logic, enabling visual configuration and unified management of the logic. Simultaneously, it ensures the security of logic calls by controlling interface access through permission verification, thus resolving the problems of fragmented logic management, difficulty in modification, and uncontrolled permissions inherent in traditional systems.

[0071] In the specific implementation process, users (such as hospital information department personnel) define data processing rules and distribution conditions through the visual configuration interface provided by the code center (such as dragging and dropping rule components and filling in parameters), forming dynamically configurable business logic (such as "outpatient examination form processing logic"). After the configuration is completed, the code center performs format validation on the logic (such as checking whether there are any conflicts in the rules). After passing the validation, it is stored in the database in a structured form (such as JSON format) and associated with a unique identifier (such as "logic ID=CHECK001").

[0072] When the event hub needs to process data, it sends a call request to the code center. The request includes the event hub's identity identifier (such as a component ID) and the identifier of the required dynamically configurable business logic (such as "the logic for processing outpatient examination form data"). The code center sends the event hub's identity identifier and the requested logic identifier to the authentication center. The authentication center queries the permission matrix to verify whether the event hub has the right to call the logic (such as "whether the event hub is authorized to call the CHECK001 logic"). If the verification fails, the code center rejects the request and returns a permission denied message; if the verification passes, the authentication center sends a "call allowed" message to the code center.

[0073] Based on feedback from the certification center, the code center opens up a call interface for dynamically configurable business logic to the event hub. The event hub obtains the complete content of this logic through the interface (including data processing rules and distribution conditions, such as "inspection order amount > 500 yuan needs to be distributed to the department head for approval" and "all inspection order events need to be stored in the data center"). When users modify the dynamically configurable business logic through the visual interface (such as adjusting the approval threshold to 800 yuan), the code center automatically updates the stored logic and synchronizes it to the call interface, ensuring that the event hub obtains the latest rules for subsequent calls.

[0074] Under the authentication and authorization of the authentication center, the process engine is used to receive standardized event data distributed by the event hub, and to trigger and execute business approval processes.

[0075] It should be noted that the process engine refers to the core component in the data foundation of this system used to automate the execution of business approval processes. It can trigger preset processes based on received standardized event data and advance each approval step according to rules to achieve an automated closed loop of business processes.

[0076] The process engine, under the authentication and authorization of the authentication center, means that the authentication center verifies the legitimacy of the process engine by verifying its identity (such as component identifier and key), and grants it the authority to receive standardized event data and trigger specific approval processes according to a preset permission matrix, so as to prevent unauthorized components from calling or exceeding their authority.

[0077] A business approval process refers to a pre-defined process based on business rules that includes multiple approval steps, each of which may involve review or approval operations by different roles.

[0078] Specifically, traditional business approval processes often rely on manual triggering (such as manually submitting application forms), which suffers from low efficiency, easy omissions, and dependence on manual judgment of process types. The process engine achieves "data-driven" automated triggering by receiving standardized event data, ensuring the timeliness and accuracy of process initiation; at the same time, relying on the permission control of the certification center, it ensures that the approval process is triggered and executed only by authorized components, avoiding illegal operations and solving the problems of "delayed triggering and chaotic permissions" in traditional processes.

[0079] In the specific implementation process, the process engine initiates an identity verification request to the certification center, submitting component identification and operation permission applications (such as "receiving hospitalization expense events and triggering approval"). After the certification center verifies and approves the application, it grants the engine the permission to receive standardized event data and trigger corresponding processes.

[0080] The process engine receives standardized event data (such as "Patient Zhang San, Medical Record No. Z2023001, Hospitalization Fee 60,000 RMB, Department Visited = Orthopedics") distributed by the event hub, performs format validation on the data (such as checking whether it contains required fields such as "Medical Record No." and "Fee Amount"), and rejects data that does not conform to the specifications. It parses the "Event Type = Hospitalization Fee Approval" and "Business Parameter = Fee 60,000 RMB" in the standardized event data and matches them with the corresponding business approval process preset in the system (such as "Hospitalization Fee > 30,000 RMB requires approval by the head nurse of the department → review by the medical insurance department → confirmation by the finance department").

[0081] Based on the matching results, the corresponding business approval process is automatically triggered, a unique process instance ID is generated, and the process status is initialized (e.g., "Pending review by the orthopedic head nurse"). The approval process proceeds according to preset steps: approval nodes are invoked (e.g., a task to be reviewed is pushed to the "orthopedic head nurse" via a message notification system, including core business parameters from standardized event data such as "patient name, hospitalization costs, and bed number"); approval results are received (e.g., the head nurse submits "Agreed, cost details are correct" through the system); the next step is advanced according to rules (e.g., "Agreed" proceeds to the medical insurance department for review, "Rejected" terminates the process and records the reason "duplicate charges exist in the cost details"). Once all approval steps are completed (or terminated), the final result (e.g., "Approval passed") is recorded and synchronized to the data center for storage, while subsequent operations can be triggered (e.g., notifying the inpatient department settlement window and linking the medical insurance system for reimbursement calculation).

[0082] Under the authentication and authorization of the authentication center, the data center is used to receive standardized event data distributed by the event hub and perform persistent storage, and to open a standard query interface with multiple parameter combinations to components that have been authenticated by the authentication center.

[0083] It should be noted that the data center is the core component of the system's data foundation, used for centralized storage of standardized event data and providing unified query services. It is the "storage hub" of the system's data and is responsible for persistent data management and secure sharing.

[0084] Under the authentication and authorization of the certification center, the data center confirms its legitimacy by verifying its identity (such as unique component identifiers and encryption keys) and grants it specific permissions to receive data, store data, and access query interfaces based on the permission matrix; at the same time, it verifies the identity of the component requesting the query and only grants query permissions to authorized components. Persistent storage refers to storing data long-term in non-volatile storage media (such as databases and disk arrays) to ensure that data is not lost after system restarts or fault recovery, unlike temporary caches (such as memory storage).

[0085] A standard query interface for multiple parameter combinations refers to a unified query interface (such as a RESTful API) provided by the data center that supports the combination of multiple query conditions (such as time range, event type, data source, etc.). The interface format is standardized, and all authorized components can call it according to the same specification, supporting flexible data filtering.

[0086] Specifically, in heterogeneous system integration scenarios, data is often scattered across various components or external systems, leading to difficulties in data reuse (e.g., queries require integration with multiple data sources), inconsistent storage formats (e.g., fields differ in different systems for the same type of event), and a lack of unified security control (e.g., unauthorized components can query freely). Data centers address this issue by centrally storing standardized event data; ensuring long-term data availability through persistent storage; enhancing data reuse flexibility through multi-parameter query interfaces; and guaranteeing data security through access control by an authentication center. Ultimately, this achieves "centralized data management, secure sharing, and flexible reuse."

[0087] In the specific implementation process, the data center initiates an identity verification request to the certification center, submitting its own component identification and functional permission application (such as "receiving and storing medical treatment event data, opening query interfaces"); after the certification center verifies and approves the application, it grants the corresponding operation permissions.

[0088] The data center receives standardized event data distributed by the event hub (such as "Outpatient visit event: Medical record number M2023002, name Li Si, department = internal medicine, visit time = 2023-10-05 09:30"), and simultaneously verifies the event hub's distribution permissions with the certification center (to ensure the data source is legitimate). After the verification is successful, the data is accepted, and data from unauthorized sources is rejected.

[0089] Persistent storage processing includes: classifying the received standardized event data according to event type (such as "outpatient visit event" and "inpatient settlement event"); writing the data into a preset relational database (such as MySQL), creating a unique index by "medical record number + event type", and associating it with fields such as "visit time" and "processing status" for easy and fast querying; and regularly performing incremental backups (such as hourly) and full backups (such as daily) on the stored data and storing it on the hospital's local server to prevent data loss.

[0090] The data center has a pre-defined standard query interface with multiple parameter combinations. Supported parameters include event type, time range, department name, and processing status (parameters are expandable). The interface format is standardized (e.g., HTTP GET request, with parameters passed via the URL query string). When other components (such as the BI center) initiate a query request, the data center sends the requesting component's identity to the authentication center to verify its query permissions (e.g., the BI center can only query "non-sensitive medical visit data"). After successful permission verification, the data center parses the multiple parameter combinations in the query request (e.g., "Event type = 'outpatient visit' and time range = '2023-10-01 to 2023-10-31' and department = 'pediatrics'"), executes the filtering logic, and returns data that meets the criteria (e.g., 1200 pediatric outpatient visits in October). If permission verification fails, a "no query permission" message is returned, ensuring no data is leaked.

[0091] In one possible implementation, a task center is also included; under the authentication and authorization of the authentication center, the task center is used to schedule the interface center to actively crawl second initial event data from external systems that provide interfaces, and to schedule the AI ​​center to crawl third initial event data from external systems without interfaces.

[0092] It should be noted that the task center refers to the functional module in the data foundation of this system used to automatically schedule the interface center and AI center to execute data collection tasks. It triggers data capture / crawl operations through preset rules and is the core scheduling unit for realizing the timed and targeted collection of multi-source initial event data.

[0093] Scheduling refers to the process by which the task center sends execution instructions to the interface center or AI center according to preset rules (such as time periods and triggering conditions), controlling them to perform data collection operations at a specified frequency or timing (e.g., "trigger data capture once a day at 3 AM"). Secondary initial event data refers to raw event data actively captured by the interface center from external systems providing standard interfaces, according to the scheduling instructions of the task center. Tertiary initial event data refers to raw event data crawled by the AI ​​center from external systems without interfaces (such as outdated desktop software or paper scanning systems), such as price information crawled from a competitor's manually updated "product price list."

[0094] The task center, under the authentication and authorization of the authentication center, means that the authentication center, by verifying the legitimacy of the task center's identity (such as component keys), grants it the authority to schedule interface centers and AI centers to execute data collection tasks, and restricts it to scheduling only tasks within a specified range (such as only allowing the scheduling of "sales data" related collection tasks).

[0095] Specifically, the data collection needs of external systems are diverse: some systems require data to be acquired periodically (such as daily sales reports), while others require data to be acquired only after specific conditions are triggered (such as when inventory falls below a threshold). Relying on manual triggering of the interface center or AI center can easily lead to omissions, delays, or operational errors, resulting in incomplete data. The task center automates and standardizes data collection tasks through unified scheduling logic, ensuring that data is acquired promptly according to business needs; simultaneously, relying on the authorization control of the authentication center, it prevents unauthorized scheduling, solving the problems of low efficiency and high risk associated with manual scheduling.

[0096] In the specific implementation process, users (such as hospital information department personnel) create data collection tasks through the visual interface of the task center and configure key information, such as: specifying the scheduling object (interface center or AI center), specifying the external system for which data needs to be collected (such as "hospital HIS system" or "old paper medical record archiving system"); setting trigger conditions (such as "execute at 08:00 every day" or "trigger when the number of inpatients exceeds 500"); and defining the specific data to be collected (such as "only collect pediatric outpatient visit data for the past 7 days").

[0097] After creating a task, the task center submits the task information (such as scheduling object = interface center, target system = HIS system) to the certification center. The certification center verifies whether the task center has the authority to schedule the object and the target system. After successful verification, a task authorization certificate is generated.

[0098] The task center stores verified tasks in the task database and monitors trigger conditions in real time according to scheduling rules (such as scheduled tasks reaching 08:00 every day, or trigger-based tasks detecting 500 hospitalized patients). When the trigger conditions are met, the task center sends a scheduling instruction to the corresponding interface center or AI center, carrying the task authorization certificate, target system information, and data range (such as "retriev pediatric outpatient data from the HIS system from October 1, 2023 to October 7, 2023").

[0099] In one possible implementation, a BI center is also included, which, under the authentication and authorization of the authentication center, is used to call the standard query interface of the data center to obtain standardized event data, perform statistical analysis, and generate serialized statistical data.

[0100] It should be noted that the BI Center refers to the functional module in this system used to perform statistical analysis on standardized event data and generate visualized or structured statistical results. Its core function is to extract business value through data mining and analysis to support decision-making.

[0101] Under the authentication and authorization of the authentication center, the BI center confirms its legitimacy by verifying its identity (such as component identifier and access key) and grants it the right to call the data center query interface and obtain standardized event data within a specific range according to the permission matrix (such as only allowing the query of "sales" data and prohibiting the query of "financial sensitive data").

[0102] A standard query interface refers to a unified interface (such as RESTAPI) provided by the data center that supports multi-parameter combination queries. The BI center obtains the required standardized event data in a standardized format through this interface.

[0103] Statistical analysis refers to the summarization, comparison, and trend analysis operations performed by the BI center on the acquired standardized event data, including but not limited to: data aggregation (such as summarizing order volume by day / month), dimensional breakdown (such as breaking down sales by region), anomaly identification (such as a sudden increase in return events), and trend prediction (such as user growth trends for the next 3 months).

[0104] Serialized statistical data refers to the analysis results that have been converted into a structured storage or transmission format (such as JSON, CSV, XML) after statistical analysis. It includes dimension labels (such as "Time = October 2023"), indicator values ​​(such as "Order Quantity = 1200 orders") and calculation logic descriptions, which are convenient for subsequent display (such as generating charts) or secondary reuse (such as transferring to other systems).

[0105] Specifically, in the data foundation system, standardized event data, after being stored, needs further value extraction (such as analyzing business trends and identifying problems). However, traditional manual analysis suffers from problems such as low efficiency (requiring manual data organization), limited dimensions (difficult to perform multi-dimensional cross-analysis), and poor real-time performance (lagging behind business changes). The BI center transforms raw data into decision-making-valuable statistical results by automating the retrieval of standardized data and performing multi-dimensional statistical analysis, solving the dilemma of "lots of data but little insight." At the same time, relying on the access control of the certification center, it ensures compliance of the analysis process and avoids the leakage of sensitive data.

[0106] In the specific implementation process, the BI center initiates an identity verification request to the certification center, submitting its own component identifier and the scope of the data to be queried (such as "to query outpatient visit data for the third quarter of 2023"). After the certification center verifies the data, it grants the BI center permission to call the corresponding query interface of the data center and returns a temporary access token.

[0107] The BI center uses a temporary access token to call the data center's standard query interface, passing in multiple parameter combinations (such as "Event type = outpatient visit & time range = 2023-07-01 to 2023-09-30 & department = internal medicine") to obtain standardized event data that meets the conditions.

[0108] Users (such as hospital operations staff) configure analysis rules through the BI center's visual interface, including: analysis dimensions (such as time, department, doctor's title); analysis indicators (such as number of visits, average treatment time, and follow-up rate); and calculation logic (such as "average monthly number of visits = total number of visits per quarter / 3" and "department follow-up rate = number of follow-up visits / total number of visits").

[0109] The BI center performs calculations on the acquired standardized event data according to configured rules: data cleaning (removing outliers, such as unreasonable records like "treatment duration = 24 hours"); multi-dimensional aggregation (e.g., cross-summarizing internal medicine visit counts by "month + doctor's title"); and trend calculation (e.g., calculating the week-on-week growth rate of internal medicine outpatient visits). The analysis results are converted into JSON format, stored in the BI center's results repository, and can be exported or integrated with visualization tools (e.g., generating a line chart of internal medicine visit trends for the third quarter).

[0110] In one possible implementation, a notification center is also included; the notification center, under the authentication and authorization of the authentication center, is used to receive calls from heterogeneous system interaction modules, event hubs, code centers, process engines, data centers, and BI centers; and to determine the specified relevant parties based on the notification object identifier in the call information.

[0111] It should be noted that the notification center refers to the functional module in the data base of this system that is used to uniformly process notification requests from various components and external systems. It is responsible for receiving calls, parsing notification objects, and distributing notification information, and serves as the hub for internal and external event notifications within the system.

[0112] The notification center, under the authentication and authorization of the authentication center, means that the authentication center confirms the legitimacy of the notification center by verifying its identity (such as the component's unique identifier and encryption key) and grants it the authority to receive and process notification requests; at the same time, it verifies whether the component / system initiating the call has the authority to use the notification service (such as only allowing the process engine to call the approval notification function).

[0113] A call refers to a notification request sent by a heterogeneous system interaction module, event hub or other component or external system to the notification center. It includes information such as notification content, notification object identifier and notification method (e.g., "The process engine calls the notification center to request an approval reminder to user A").

[0114] The call information refers to the data passed when initiating a call, including the caller identifier (e.g., "process engine"), notification content (e.g., "You have a purchase approval pending"), notification recipient identifier (e.g., user ID "user001"), and notification method (e.g., SMS, system message). The notification recipient identifier is a unique identifier used to identify the relevant party who needs to receive the notification, and can be a user ID, department code, role name, external system account, etc. (e.g., "dept002" represents the finance department, "role003" represents the approver). The designated relevant party refers to the individual, department, role, or external system that needs to receive the notification, as determined by the notification recipient identifier.

[0115] Specifically, various system components and external systems frequently trigger notifications during operation (e.g., the workflow engine needs to remind users to approve data, and the event hub needs to inform external systems of data processing results). If each component implements notification functionality independently, it will lead to fragmented notification logic, inconsistent formats, and chaotic access control (e.g., unauthorized components sending sensitive notifications). The notification center, as a unified notification hub, centrally processes all notification requests. Through standardized API calls and access control, it solves the problems of fragmented notification logic and insufficient security, ensuring that relevant parties receive accurate information in a timely manner.

[0116] In the specific implementation process, the notification center initiates identity verification with the authentication center, submitting component identifiers and permission requests; after the authentication center verifies the information, it grants the corresponding permissions. The notification center receives call requests from heterogeneous system interaction modules, event hubs, code centers, process engines, data centers, or BI centers, and simultaneously verifies the initiator's permissions (confirming with the authentication center whether the caller has the right to initiate the notification), rejecting unauthorized calls. It extracts key information from the call information, such as the notification object identifier (e.g., "user001"), notification content, and notification method, and verifies the format's legality (e.g., checking if the notification object identifier exists in the system address book). Based on the notification object identifier, it queries the system address book or associated mapping table (e.g., "user001" corresponds to user "Li Si") to determine the designated relevant parties who need to receive the notification. According to the notification method in the call information (e.g., SMS, in-system message, email, API push to external systems), it sends the notification content to the relevant parties and records the notification status (e.g., "delivered" or "unread").

[0117] In one possible implementation, the process engine is also used to interact with lower-level process engines; the process engine dispatches process events to the lower-level process engines under the authentication and authorization of the authentication center; the lower-level process engines receive and process the process events under the authentication and authorization of the authentication center, and report the processing results and real-time processing status of the process events to the external system of the process engine.

[0118] It should be noted that the process engine refers to the core component in the data foundation of this system that is responsible for the overall management of cross-level business processes. It has the functions of initiating processes, assigning tasks, and receiving feedback. It can be understood as the "superior process node" and is suitable for handling global or cross-scope business approvals (such as the process hub of a corporate headquarters or the process management module of a hospital's main branch).

[0119] Lower-level process engines refer to components controlled by the process engine that are responsible for handling local or segmented processes. They are extensions of the process engine at lower levels (such as process nodes in branch offices or process processing modules in hospital departments) and only handle specific tasks assigned by the process engine.

[0120] Interaction refers to the two-way data transfer between the process engine and the subordinate process engine, including the process engine dispatching process events to the subordinate and the subordinate reporting processing results and status to the superior, and information exchange is achieved through standardized interfaces.

[0121] Process events refer to specific business tasks that need to be processed by lower-level process engines. They include information such as task content, processing rules, and time limits, and are the core objects dispatched by the process engine.

[0122] Delegation refers to the process engine assigning process events to a designated subordinate process engine according to permissions and business rules. It includes key information such as event data, processing permission scope, and callback interface.

[0123] The processing result refers to the final conclusion generated by the lower-level process engine after completing the process event, and it must contain traceable business data.

[0124] Real-time processing status refers to the dynamic progress reported by the lower-level process engine during processing, which is used by the process engine to monitor task progress in real time.

[0125] The process engine, under the authentication and authorization of the authentication center, means that the authentication center verifies the identity and legitimacy of the process engine and its subordinate process engines (such as unique component identifiers and encryption keys) and grants corresponding operation permissions (such as only allowing the process engine to assign tasks to designated subordinates, and subordinates can only report results within their own permission scope).

[0126] Specifically, in multi-level organizational structures (such as group companies and multi-level hospitals), business processes often require cross-level collaboration (e.g., approvals initiated by headquarters require initial review by branch offices, and consultation processes in the head office require execution by departments). Relying solely on a single process engine would lead to inefficiency due to the broad scope of business and difficulty in adapting to the segmented rules of different levels. A hierarchical architecture of "process engine + subordinate process engines" enables a division of labor between "global coordination and local execution": the process engine is responsible for initiating and monitoring global processes, while subordinate engines focus on handling tasks in specific sub-domains. This solves the problem of a single engine being unable to cover complex multi-level business processes, while access control through an authentication center ensures secure interaction.

[0127] In the specific implementation process, the process engine initiates a request to the certification center to verify its dispatching authority, and obtains a dispatching authorization credential upon successful verification. Subordinate process engines also initiate requests to the certification center to verify their receiving and processing authority, and obtain receiving authorization credentials upon successful verification. Based on business rules, the process engine packages process events (including event ID, task content, processing rules, and callback address); carrying the dispatching authorization credential, it sends the process event to the designated subordinate process engine through a standardized interface, while simultaneously recording logs such as dispatching time and event type. The subordinate process engine verifies the legitimacy of the process event's source (confirming with the certification center whether it was dispatched by an authorized process engine), rejecting unauthorized dispatches; it executes the local process according to the processing rules in the process event (e.g., a branch office reviews materials for a purchase application, or a department doctor issues an examination order based on consultation needs); and it provides real-time feedback on the processing status to the process engine. After completing processing, the subordinate process engine generates a processing result and reports it to the process engine through a callback interface, carrying its own authorization credential. The process engine receives the processing result and status, updates the global process progress, and intervenes in abnormal states (e.g., coordinating supplementary data and re-dispatching), until the process event is completely closed.

[0128] It should be noted that traditional authentication systems can only achieve basic identity verification (such as "who can log in"), and their authorization logic is mostly based on fixed roles, making it difficult to adapt to the needs of multi-source identity access and fine-grained data management in heterogeneous system integration scenarios. The authentication center in this application is the core component of this system responsible for unified identity verification and fine-grained permission authorization. It deeply integrates multimodal authentication and data asset-level authorization capabilities, not only solving the problem of who is who for the user / component, but also controlling which specific data can be processed and which operations can be performed through dynamic policies. It is the core of the system's security architecture.

[0129] Specifically, the certification center supports a diverse set of authentication methods, including but not limited to account passwords, SSO (single sign-on), SMS verification, and third-party system authorization (such as integration with WeChat Work and LDAP), which can be flexibly adapted according to system type.

[0130] In its implementation, the certification center employs a refined authorization model that uses a combination of user attributes (such as department and role), data attributes (such as data table, field, and sensitivity), and environmental attributes (such as login device and time) to achieve data asset-level access control, unlike traditional coarse-grained role-based authorization. The certification center also has a mechanism to adjust the authorization scope in real time based on the authentication context (such as authentication method security and login environment). For example, strong authentication (SSO + SMS verification) corresponds to highly sensitive data access permissions, while weak authentication (account and password only) corresponds to basic data permissions.

[0131] Example 2 provides a data infrastructure system and event processing method based on an event hub, applied to the aforementioned data infrastructure system based on an event hub, such as... Figure 2 As shown, it includes the following steps:

[0132] Step 1: Under the authentication and authorization of the authentication center, the heterogeneous system interaction module interacts with the external system to obtain multi-source initial event data and transmits the multi-source initial event data to the event hub.

[0133] Step 2: Under the authentication and authorization of the authentication center, the event hub calls the dynamically configurable business logic stored in the code center to clean, process and verify the multi-source initial event data obtained in Step 1, and generate standardized event data.

[0134] Step 3: Based on the distribution conditions included in the dynamically configurable business logic, the event hub determines the distribution path of the standardized event data generated in Step 2, and distributes the standardized event data to at least one component of the process engine, data center, and heterogeneous system interaction module. If the event hub distributes the standardized event data to the process engine, then proceed to Step 4; if the event hub distributes the standardized event data to the data center, then proceed to Step 5; if the event hub distributes the standardized event data to the heterogeneous system interaction module, then proceed to Step 6.

[0135] Step 4: Under the authentication and authorization of the authentication center, the process engine receives the standardized event data distributed in Step 3, triggers and executes the business approval process.

[0136] Step 5: Under the authentication and authorization of the authentication center, the data center receives the standardized event data distributed in Step 3, performs persistent storage, and opens a standard query interface with multiple parameter combinations to components that have been authenticated by the authentication center.

[0137] Step 6: Under the authentication and authorization of the authentication center, the heterogeneous system interaction module receives the standardized event data distributed in Step 3 and distributes it to external systems.

[0138] The embodiments described above are merely illustrative of specific implementations of the present invention, and while the descriptions are detailed, they should not be construed as limiting the scope of the present invention. It should be noted that those skilled in the art can make various modifications and improvements without departing from the concept of the present invention, and these modifications and improvements all fall within the scope of protection of the present invention.

Claims

1. An event hub-based data repository system, characterized by, The data foundation includes multiple modular components, including a heterogeneous system interaction module, an event hub, a code center, a process engine, a data center, and an authentication center. Under the authentication and authorization of the authentication center, the heterogeneous system interaction module is used to interact with external systems to obtain multi-source initial event data and output the multi-source initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and distribute the standardized event data to external systems. Under the authentication and authorization of the authentication center, the event hub is used to receive multi-source initial event data output by the heterogeneous system interaction module, call the dynamically configurable business logic stored in the code center to clean, process and verify the multi-source initial event data, generate standardized event data, determine the distribution path of the standardized event data based on the distribution conditions included in the dynamically configurable business logic, and distribute the standardized event data to the process engine, data center and heterogeneous system interaction module according to the distribution path. The code center is used to store dynamically configurable business logic; wherein, the dynamically configurable business logic includes data processing rules and distribution conditions, and the code center opens the calling interface of the dynamically configurable business logic to the event hub after the authentication center verifies the calling permission of the event hub. Under the authentication and authorization of the authentication center, the process engine is used to receive standardized event data distributed by the event hub, trigger and execute business approval processes; Under the authentication and authorization of the authentication center, the data center is used to receive standardized event data distributed by the event hub and perform persistent storage, and to open a standard query interface with multiple parameter combinations to components that have been authenticated by the authentication center. The heterogeneous system interaction module includes an interface center and an AI center, and the multi-source initial event data includes first initial event data, second initial event data and third initial event data; Under the authentication and authorization of the authentication center, the interface center is used to receive first initial event data pushed by external systems, or actively capture second initial event data from external systems, and output the first initial event data or the second initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and push the standardized event data to the external systems that provide the interface; The AI ​​center integrates a user interface automated interaction tool, which, under the authentication and authorization of the authentication center, is used to crawl third-party multi-source initial event data from external systems without interfaces and output the third-party multi-source initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and write the standardized event data back to the external systems without interfaces through the user interface automated interaction tool. The dynamically configurable business logic stored in the code center supports user-defined configurations. Users can modify data processing rules and distribution conditions through the visual configuration interface provided by the code center. The modified dynamically configurable business logic takes effect after the authentication center verifies the user's operation permissions and synchronizes it to the event hub's call interface.

2. The data foundation system based on an event hub according to claim 1, characterized in that, It also includes a task center; under the authentication and authorization of the authentication center, the task center is used to schedule the interface center to actively crawl the second initial event data from the external system that provides the interface, and to schedule the AI ​​center to crawl the third initial event data from the external system without the interface.

3. An event hub-based data repository system according to claim 1, wherein, It also includes a BI center, which, under the authentication and authorization of the authentication center, is used to call the standard query interface of the data center to obtain standardized event data, perform statistical analysis, and generate serialized statistical data.

4. An event hub-based data repository system according to claim 3, wherein, It also includes a notification center; under the authentication and authorization of the authentication center, the notification center is used to receive calls from heterogeneous system interaction modules, event hubs, code centers, process engines, data centers and BI centers; and to determine the specified relevant parties based on the notification object identifier in the call information.

5. An event hub-based data repository system according to claim 1, wherein, The process engine is also used to interact with lower-level process engines; under the authentication and authorization of the authentication center, the process engine dispatches process events to the lower-level process engines. Under the authentication and authorization of the authentication center, the lower-level process engine receives and processes the process events, and reports the processing results and real-time processing status of the process events to the external system of the process engine.

6. An event processing method for an event hub-based data foundation system, the method comprising: The data infrastructure system based on an event hub, as described in any one of claims 1-5, comprises the following steps: Step 1: Under the authentication and authorization of the authentication center, the heterogeneous system interaction module interacts with the external system to obtain multi-source initial event data and transmits the multi-source initial event data to the event hub. Step 2: Under the authentication and authorization of the authentication center, the event hub calls the dynamically configurable business logic stored in the code center to clean, process and verify the multi-source initial event data obtained in Step 1, and generate standardized event data. Step 3: Based on the distribution conditions included in the dynamically configurable business logic, the event hub determines the distribution path of the standardized event data generated in Step 2, and distributes the standardized event data to at least one component of the process engine, data center, and heterogeneous system interaction module; if the event hub distributes the standardized event data to the process engine, then proceed to Step 4; if the event hub distributes the standardized event data to the data center, then proceed to Step 5; if the event hub distributes the standardized event data to the heterogeneous system interaction module, then proceed to Step 6. Step 4: Under the authentication and authorization of the authentication center, the process engine receives the standardized event data distributed in Step 3, triggers and executes the business approval process; Step 5: Under the authentication and authorization of the authentication center, the data center receives the standardized event data distributed in Step 3, performs persistent storage, and opens a standard query interface with multiple parameter combinations to components that have been authenticated by the authentication center. Step 6: Under the authentication and authorization of the authentication center, the heterogeneous system interaction module receives the standardized event data distributed in Step 3 and distributes it to external systems; The heterogeneous system interaction module includes an interface center and an AI center, and the multi-source initial event data includes first initial event data, second initial event data and third initial event data; Under the authentication and authorization of the authentication center, the interface center is used to receive first initial event data pushed by external systems, or actively capture second initial event data from external systems, and output the first initial event data or the second initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and push the standardized event data to the external systems that provide the interface; The AI ​​center integrates a user interface automated interaction tool, which, under the authentication and authorization of the authentication center, is used to crawl third-party multi-source initial event data from external systems without interfaces and output the third-party multi-source initial event data to the event hub; it is also used to receive standardized event data distributed by the event hub and write the standardized event data back to the external systems without interfaces through the user interface automated interaction tool. The dynamically configurable business logic stored in the code center supports user-defined configurations. Users can modify data processing rules and distribution conditions through the visual configuration interface provided by the code center. The modified dynamically configurable business logic takes effect after the authentication center verifies the user's operation permissions and is synchronized to the event hub's call interface.

Images