Method, system and device for supporting multi-process data supply and demand docking and storage medium

Abstract

The invention relates to the technical field of data processing, and particularly provides a method, system and device for supporting multi-process data supply and demand connection and a storage medium, and the method comprises the steps: receiving a data demand which is submitted by a demand side and contains demand content and information items; after the demand is automatically checked, whether a third party needs to intervene in coordination or not is judged based on a preset rule; if not, directly distributing the demand to a target data providing department for processing; and if yes, the demand is routed to a third-party coordination end for summarization or decomposition processing, and then a result is distributed to a target department. According to the invention, by introducing an automatic checking and intelligent process decision-making mechanism, the overall efficiency of data supply and demand docking is significantly improved.

Description

Technical Field

[0001] This invention belongs to the field of data processing technology, specifically relating to a method, system, device, and storage medium that supports multi-process data supply and demand docking. Background Technology

[0002] In the field of government data sharing and exchange, a data catalog publishing and application mechanism based on a unified service portal has been widely established. However, when the data catalog is missing or incomplete, the supply and demand matching process relying on manual processing exposes a series of problems. Existing systems typically employ a single, fixed processing path, which cannot flexibly adapt to diverse real-world scenarios: when the requester clearly knows the data provider, mandatory third-party intervention in the approval process leads to redundancy and inefficiency; while when the requester cannot determine the responsible department, the lack of an intelligent routing mechanism leaves the request suspended and unable to be accurately delivered. Furthermore, different regions have varying levels of data governance maturity; some regions require in-depth coordination from the competent authorities, while others only require basic channels. This "one-size-fits-all" approach to processes has become a bottleneck restricting the efficient flow and accurate service of data elements, failing to meet the increasingly complex cross-departmental and multi-scenario data supply and demand matching needs. Summary of the Invention

[0003] In view of the above-mentioned shortcomings of the prior art, the present invention provides a method, system, device and storage medium that supports multi-process data supply and demand docking to solve the above-mentioned technical problems.

[0004] In a first aspect, the present invention provides a method for supporting multi-process data supply and demand docking, comprising: Receive data requests submitted by the requester, wherein the data requests include at least the request content and one or more request information items; The data requirements are automatically verified, and after verification, based on preset decision rules, it is determined whether third-party intervention and coordination are needed when processing the data requirements. In response to the determination that no third-party intervention is required, the data request is directly distributed to one or more target data provider departments for claiming and processing. In response to the determination that third-party intervention is required, the data request is routed to the third-party coordinator, which then aggregates or decomposes the data request and distributes the processed data request to the target data provider.

[0005] In an optional implementation, after the data request is claimed and confirmed for provision by the data provider, the step of providing data resources is further included: Associate the confirmed data requirements with the specified data resources; The associated data resources are then provided to the requesting party.

[0006] In one optional implementation, receiving data requests submitted by the requester includes: A structured input interface is provided through a requirement submission module; The interface receives at least the following fields from the requester: request name, request content, and one or more standardized request information items. The required information items are in a standard data element format.

[0007] In one optional implementation, the data requirement is automatically verified, including: Perform basic integrity checks, including non-empty checks and format compliance checks on key fields in the requirement name, requirement content, and requirement information items; Perform business rationality verification, including verifying departmental permissions based on the functional scope of the department submitting the requirements, and / or comparing current requirements with historical requirements to perform duplicate requirement detection; If the verification fails, a rejection and correction operation is triggered; if the verification passes, a subsequent process branch decision is triggered.

[0008] In an optional implementation, based on preset decision rules, it is determined whether third-party intervention and coordination are required when processing the data request, including: Parse the data requirements and extract at least one requirement information item as a matching keyword; In the predefined global data responsibility matrix, query one or more responsible departments corresponding to each of the aforementioned requirement information items; Aggregate query results and output decision signals for process branches based on the aggregated results; If all demand information items point to the same responsible department, then output a decision signal indicating direct distribution. If the required information item points to multiple different responsible departments, a decision signal indicating that third-party intervention is needed for decomposition will be output. If any requirement information item is not matched with any responsible department in the global data responsibility matrix, a decision signal indicating that third-party intervention is needed for coordination is output.

[0009] In an optional implementation, before summarizing or decomposing the data requirements, the method further includes: The data requirements are automatically identified to determine their processing type: If the text similarity algorithm identifies a text that is more similar to an existing requirement than the threshold, it is determined that automatic aggregation processing is required. If, based on the global data responsibility matrix, the required information item of the data requirement is identified as belonging to multiple different departments, it is determined that automatic decomposition processing is required. If the similarity between the data requirement and the existing requirement does not exceed the threshold and the requirement information items do not belong to multiple different departments, it is determined to be a simple requirement that can be directly distributed.

[0010] In one optional implementation, the third-party coordinator aggregates or decomposes the data requirements and distributes the processed data requirements to the target data provider departments, including: If automatic summary processing is performed, the steps include: By calculating the text similarity between the current data requirement and the existing requirements in the system, the current requirement and the existing requirements with similarity exceeding a preset threshold are automatically merged into the same requirement group. Cluster analysis is performed on all requirements within the aforementioned requirement group, and a standardized summary requirement topic is automatically generated. Based on the global data responsibility matrix, one or more main responsible departments are intelligently recommended for the aggregated demand topic; Distribute the summarized requirements to the recommended responsible departments; If automatic decomposition is performed, the steps include: Using the aforementioned requirement information item as the smallest unit, it is matched with the global data responsibility matrix to determine the corresponding responsible department for each data item; Based on the matching results, the data requirements are automatically broken down into multiple sub-requirements, each of which is associated with a target responsible department and the specific data items it needs to provide. The multiple sub-requirements are distributed in parallel to their respective target data providing departments.

[0011] Secondly, the present invention provides a system that supports multi-process data supply and demand docking, comprising: The requirement receiving module is used to receive data requirements submitted by the requester. The data requirements include at least the requirement content and one or more requirement information items. The demand coordination module is used to automatically verify the data demand, and after the verification is passed, it determines whether third-party intervention is needed to coordinate the processing of the data demand based on preset decision rules. The direct distribution module is used to directly distribute the data request to one or more target data provider departments for claiming and processing in response to the determination that no third-party intervention is required. The intervention processing module is used to respond to the determination that third-party intervention is required, route the data request to the third-party coordinating end, and have the third-party coordinating end summarize or decompose the data request and distribute the processed data request to the target data providing department.

[0012] Thirdly, a device is provided, comprising: The memory is used to store programs that support the data supply and demand interaction across multiple processes; The processor, when executing the program that supports multi-process data supply and demand docking, implements the steps of the method for supporting multi-process data supply and demand docking as provided in the first aspect.

[0013] Fourthly, a computer-readable storage medium is provided, on which a program supporting multi-process data supply and demand docking is stored, wherein when the program supporting multi-process data supply and demand docking is executed by a processor, the program implementing the steps of the method supporting multi-process data supply and demand docking provided in the first aspect is implemented.

[0014] The beneficial effects of this invention lie in the fact that the method, system, equipment, and storage medium provided by this invention, which support multi-process data supply and demand matching, significantly improve the overall efficiency of data supply and demand matching by introducing automated verification and intelligent process decision-making mechanisms. The system can automatically identify demand characteristics and flexibly select point-to-point direct distribution or third-party coordination paths, effectively avoiding redundant steps and resource waste caused by traditional single processes. Through intelligent aggregation and precise decomposition functions, the system achieves the merging of common demands and the parallel distribution of complex demands, not only shortening response time but also ensuring precise matching between demands and providing departments, thereby improving data processing capabilities while fully meeting the differentiated process requirements in different scenarios. Attached Figure Description

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

[0016] Figure 1 This is a schematic flowchart of a method according to an embodiment of the present invention.

[0017] Figure 2 This is a schematic block diagram of a system according to an embodiment of the present invention.

[0018] Figure 3 This is a schematic diagram of the structure of a device provided in an embodiment of the present invention. Detailed Implementation

[0019] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions of the embodiments of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.

[0020] Unless otherwise defined, all technical and scientific terms used herein have the same meaning as commonly understood by one of ordinary skill in the art to which this invention pertains. The terminology used herein in the description of the invention is for the purpose of describing particular embodiments only and is not intended to be limiting of the invention.

[0021] The method for supporting multi-process data supply and demand docking provided in this embodiment of the invention is executed by a computer device, and correspondingly, the system supporting multi-process data supply and demand docking runs on the computer device.

[0022] Figure 1 This is a schematic flowchart illustrating a method according to an embodiment of the present invention. Wherein, Figure 1 The executing entity can be a system that supports multi-process data supply and demand integration. Depending on different needs, the order of steps in this flowchart can be changed, and some can be omitted.

[0023] like Figure 1 As shown, the method includes: S1. Receive data requests submitted by the requester, wherein the data requests include at least the request content and one or more request information items; S2. Perform automated verification of the data requirements, and after verification, determine whether third-party intervention and coordination are needed when processing the data requirements based on preset decision rules; S3. In response to the determination that no third-party intervention is required, the data request is directly distributed to one or more target data providing departments for claiming and processing; S4. In response to the determination that third-party intervention is required, the data request is routed to the third-party coordinator, and the third-party coordinator summarizes or decomposes the data request and distributes the processed data request to the target data provider.

[0024] In one embodiment of the present invention, based on step S1, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0025] S101. Provides a structured input interface The system provides a structured online form interface to the requester (usually a department operator). This interface is not a simple free text box, but consists of multiple fields with clear labels and input specifications. It aims to guide users to input their requirements completely and in a standardized manner, transforming unstructured requirements into standardized data objects that the system can process from the source.

[0026] S102. Receive structured input fields In the interface, the system receives and validates at least the following core fields of user input: Requirement Name: A concise title used to quickly identify the main point of the requirement. The front-end can impose a length limit (e.g., no more than 100 characters) and perform non-empty validation on it.

[0027] Requirements: A text area for users to describe in detail the business purpose, application scenarios, and other background information of the data. This will be the primary data source for subsequent natural language processing analysis.

[0028] One or more standardized requirement information items: This is crucial for subsequent automated matching. Users must explicitly specify the required data fields here. To achieve this, the system preferably adopts one of the following two methods: a) Standard Data Element Selector: The system provides a searchable, drop-down selection library of standard data elements. Users can select from a predefined directory of data elements that conform to national or industry standards (such as the "Government Data Element Specification") by entering keywords. For example, after a user enters "enterprise," the system will suggest standard data elements such as "enterprise name," "enterprise unified social credit code," and "enterprise registered address" for selection.

[0029] b) Standardized input box and validation: The system provides a text input box, but the backend service will perform real-time or submission format validation on the content entered by the user, forcing it to conform to the naming convention of standard data elements (such as "data item name_category_format").

[0030] S103. Implement standard data element format The phrase "requirement information item is in standard data element format" means that at the system's underlying level and during data transmission, this information item is represented as a structured object, rather than plain text. For example, in a database table, a requirement information item might be recorded as: {"dataElementCode": "GS_01_001", "dataElementName": "Enterprise Unified Social Credit Code", "dataType": "character type", "length": "18"} In this way, the system ensures the unambiguity and machine readability of the requirement information items, laying a solid data foundation for subsequent accurate matching with the "global data responsibility matrix".

[0031] In one embodiment of the present invention, based on step S2, the following will provide a possible embodiment and describe its specific implementation in a non-limiting manner.

[0032] The automated verification and process branch decision-making functions are implemented by an integrated rules engine module. This module can be a standalone service built on Java Drools, Python Rule Engine, or similar technologies, and its specific workflow is as follows: S201. Specific Implementation of Automated Verification Basic integrity verification: Non-null validation: After a requirement is submitted, the system automatically checks whether the values ​​of key fields such as "Requirement Name," "Requirement Content," and "Requirement Information Items" are NULL or empty strings. For example, this can be implemented using a simple piece of code: if (request.getName() == null || request.getName().trim().isEmpty()) { / / Triggered rejection correction, prompting "Request name cannot be empty"} Format compliance verification: The system calls predefined format verification rules. For example, it checks whether the length of the "requirement name" is between 1 and 100 characters; and uses regular expressions to verify whether the "requirement information item" conforms to the encoding format of standard data elements (such as ^[AZ]{2}_\\d{2}_\\d{3}$).

[0033] Business rationality verification: Departmental permission verification: The system maintains a "department-data function" mapping table. During verification, the engine compares the ID of the department submitting the request with the typical responsible department scope associated with the request information item. For example, if the civil affairs department submits a request with the information item "enterprise import and export customs declaration", the system will mark the request as "low relevance" or directly trigger an alarm.

[0034] Duplicate Request Detection: The system uses a text similarity algorithm (such as cosine similarity based on TF-IDF features) to calculate the similarity between the current "requirement content" and recently submitted requests from this department. If the similarity exceeds a set threshold (such as 90%), the system will automatically prompt the operator to confirm whether it is a duplicate submission, or forcibly associate it with a historical request.

[0035] Processing of verification results: If any validation fails, the rules engine will immediately generate a structured rejection correction instruction, which includes the error code and specific modification suggestions, and notify the original operator through the message service.

[0036] Once all validations pass, the rules engine will generate a validation pass event, which will automatically trigger subsequent process branch decision-making processes.

[0037] S202. Specific Implementation of Process Branch Decisions Analysis and Keyword Extraction: The rules engine receives the approved requirement objects and extracts a precise list of "requirement information items" from them. These information items, because they are in a standard data element format, are themselves standardized and unambiguous query keywords.

[0038] Query the global data responsibility matrix: The system maintains a database table or cache named `data_responsibility_matrix`, whose core fields include: `data_element_code` (data element code), `dept_id` (responsible department ID), and `dept_name` (department name). The decision engine uses each extracted requirement information item (i.e., the data element code) as a query keyword to execute an SQL query or cache lookup. SELECT dept_id, dept_name FROM data_responsibility_matrix WHERE data_element_code = #{currentDataElementCode}.

[0039] Aggregated query results and decision logic: The engine aggregates the query results of all required information items and executes the following core decision logic: Scenario 1: Direct Distribution. If all demand information items correspond to the same dept_id, meaning they uniquely point to the same responsible department, the engine outputs the ROUTE_DIRECT decision signal.

[0040] Scenario 2: Decomposition Required. If the requirement information item corresponds to two or more different dept_ids, the engine outputs the ROUTE_COORDINATION_SPLIT decision signal, indicating that third-party intervention is required for decomposition.

[0041] Scenario 3: Coordination Required. If no matching record is found for any required information item in the matrix (the query result is empty), the engine outputs the ROUTE_COORDINATION_ASSIGN decision signal, indicating that third-party intervention is needed to clarify the responsible department.

[0042] In one embodiment of the present invention, based on steps S3 and S4, a possible embodiment will be given below, and its specific implementation will be described in a non-limiting manner.

[0043] S3. In response to the determination that no third-party intervention is required, the data request is directly distributed to one or more target data provider departments for claiming and processing.

[0044] When the rules engine outputs the ROUTE_DIRECT decision signal, the workflow engine (such as Activiti or Camunda) automatically triggers a "direct distribution" task. This system task calls a RESTful API, passing the data request object and its clearly defined target department ID list as parameters, and pushes it to the "requirement claiming module." This module then creates a "pending claim" requirement in the corresponding department's to-do list and sends a reminder via internal system notifications or integrated external communication tools (such as DingTalk or WeChat Work), thereby achieving accurate and rapid direct delivery of the requirement.

[0045] S4. In response to the determination that third-party intervention is required, the data request is routed to the third-party coordinator, and the third-party coordinator summarizes or decomposes the data request and distributes the processed data request to the target data provider.

[0046] When the rules engine outputs a ROUTE_COORDINATION_SPLIT or ROUTE_COORDINATION_ASSIGN decision signal, the workflow engine routes the request to the "intelligent processing center." Before proceeding with specific processing, the system first initiates an automatic identification sub-process to determine the optimal processing type: Automatically identify processing type: Summary Processing and Identification: The system uses text similarity algorithms (such as semantic similarity calculation based on Sentence-BERT) to compare the "requirement content" of the current request with requests in the system that are "processing" or "pending acceptance" in pairs. If there are requests with similarity scores exceeding a preset threshold (e.g., 0.85), they are determined to require automatic summary processing.

[0047] Decomposition Processing Identification: The system directly utilizes the intermediate results from the aforementioned process branch decisions. If the decision signal is ROUTE_COORDINATION_SPLIT (i.e., the requirement information item has been identified as belonging to multiple different departments), it is directly determined that automatic decomposition processing is required.

[0048] Simple Request Identification: If neither of the above two conditions is met (i.e., there are no high similarity requests and the responsible department is singular or needs to be designated), it is determined to be a simple request that can be directly distributed, and it will be directly assigned after being reviewed by the coordinating operator.

[0049] If a process is identified as requiring aggregation, the system performs the following automated steps: Merging Requirement Groups: The system logically associates the current requirement with all historical requirements whose similarity exceeds a threshold in the database to form a virtual "requirement group" and assigns it a unique group ID.

[0050] Clustering and Topic Generation: The system uses text clustering algorithms (such as K-Means) to analyze all the "requirement content" of the requirement group, and uses keyword extraction technology (such as TextRank) to automatically generate a standardized summary requirement topic, such as "Summary of requirements for joint verification of enterprise environmental protection and tax information".

[0051] Intelligent department assignment: Based on the "global data responsibility matrix", the system analyzes all data items involved in the summary topic and calculates one or more departments with the highest correlation as recommended responsible departments.

[0052] Distribution: The system automatically creates a new "Summary Requirements" task representing the entire requirements group and distributes it to the recommended responsible departments. Simultaneously, the system sends a notification to all stakeholders with original requirements within the group, informing them that their requirements have been summarized and processed.

[0053] If it is identified as requiring decomposition, the system performs the following automated steps: Data Item-Department Mapping: The system uses the requirement information item (standard data element) as the smallest unit and performs precise matching with the "global data responsibility matrix" to determine the unique or primary responsible department for each data item.

[0054] Generating Sub-Requirements: Based on the mapping results, the system automatically creates multiple parallel sub-requirement tasks. Each sub-requirement task inherits the metadata of the parent requirement, but the "Required Data Items" field only contains the data elements assigned to that department, while the "Target Department" field explicitly points to that department. All sub-requirements are associated with the parent requirement ID.

[0055] Parallel distribution: The workflow engine triggers and pushes these sub-requirements in parallel (rather than serially) to the "requirement claiming module", thereby simultaneously distributing them to the corresponding target data providing departments, which greatly shortens the overall processing cycle of complex requirements.

[0056] Based on the above embodiments, in one embodiment, after the data request is claimed and confirmed for provision by the data providing department, the step of providing data resources is further included: 1. Association Preparation and Triggering When the data provider makes a "confirm provision" operation in the "requirement assignment module", the system workflow engine will trigger a status update, setting the status of the requirement to "confirmed, pending association", and automatically generating a pending task in the "resource association module", which will be listed in the department's "requirement responsibility list".

[0057] 2. Specific implementation of resource association When a department operator enters this module, selects the requirement to be processed, and clicks the "Associate Resources" button, the system performs the following operations: a. Requirement details review: The interface displays the "Requirement Name", "Requirement Content" and "Requirement Information Items" of the requirement again for the operator to make a final confirmation and ensure that the associated resources can accurately match the requirement.

[0058] b. Select and execute the association method: The system provides two core association methods: Method 1: Link to existing data catalog resources (preferred method). The system calls the list of data services published by this department in the unified data catalog via internal API. Operators can search by resource name, code, or keyword, and select the best matching data service API interface or database table with a status of "shareable" from the returned list. The system records the unique identifier of the resource (e.g., resource_id).

[0059] Method 2: Upload newly created data resource files. For temporarily prepared data that does not need to be entered into a directory, the system provides a file upload component. Operators can click the upload button, select a locally prepared data file (such as Excel or CSV format), and the system will store it in a file server or object storage, generating a unique file access address (URL).

[0060] c. Configuration Parameters: After selecting or uploading resources, operators need to fill in the key provision parameters that form the Service Level Agreement: Data update cycle: Select via drop-down menu, such as "Real-time", "Daily", "Weekly" or "Monthly".

[0061] Provision method: Automatic display or manual selection based on the selected resource, such as "API interface call", "database table exchange" or "file download".

[0062] d. Submission and Audit: Before submitting, the operator must briefly describe the association details in the "Processing Comments" text box (e.g., "It has been associated with the 'Enterprise Basic Information Query' service and can be accessed via API key"). After clicking submit, the system will persistently store all association information (resource ID / URL, provided parameters, processing comments, operation timestamp) to form a complete audit log.

[0063] 3. Specific Implementation of Resource Provision After the association operation is successfully submitted, the system will automatically execute the following process: a. Status Update and Notification: The system will eventually update the status of the request to "Associated, Pending Use" and immediately trigger the notification service.

[0064] b. Delivering resources to the demand side: If the associated API interface is involved, the system sends a notification to the requesting party, which includes the detailed API call address, necessary authentication information (such as the API Key), and a link to the usage documentation.

[0065] If the associated file is a file, the system sends a notification to the requester containing a time-sensitive file download link.

[0066] c. Closed-loop process: After receiving the notification, the requesting party can obtain the data through the provided methods. At this point, the entire data supply and demand matching process is closed, and the system records the completion of the process.

[0067] In some embodiments, the system supporting multi-process data supply and demand integration may include multiple functional modules composed of computer program segments. The computer programs of each program segment in the system supporting multi-process data supply and demand integration may be stored in the memory of a computer device and executed by at least one processor to perform (see details). Figure 1 (Description) Supports the function of connecting data supply and demand across multiple processes.

[0068] In this embodiment, the system supporting multi-process data supply and demand docking can be divided into multiple functional modules according to the functions it performs, such as... Figure 2 As shown. The module referred to in this invention is a series of computer program segments that can be executed by at least one processor and perform a fixed function, and is stored in memory. In this embodiment, the functions of each module will be described in detail in subsequent embodiments.

[0069] The requirement receiving module is used to receive data requirements submitted by the requester. The data requirements include at least the requirement content and one or more requirement information items. The demand coordination module is used to automatically verify the data demand, and after the verification is passed, it determines whether third-party intervention is needed to coordinate the processing of the data demand based on preset decision rules. The direct distribution module is used to directly distribute the data request to one or more target data provider departments for claiming and processing in response to the determination that no third-party intervention is required. The intervention processing module is used to respond to the determination that third-party intervention is required, route the data request to the third-party coordinating end, and have the third-party coordinating end summarize or decompose the data request and distribute the processed data request to the target data providing department.

[0070] Figure 3 The method for supporting multi-process data supply and demand docking provided in the embodiments of this application can be applied to devices. Those skilled in the art will understand that the device structure involved in the embodiments of this invention does not constitute a limitation on the device. A device may include more or fewer components than illustrated, or combine certain components, or have different component arrangements. In the embodiments of this invention, the device includes, but is not limited to, laptop computers, desktop computers, workstations, personal digital assistants, servers, blade servers, mainframe computers, and other suitable computers. The device may also represent various forms of mobile devices, such as personal digital processors, cellular phones, smartphones, wearable devices, and other similar computing devices. The components shown herein, their connections and relationships, and their functions are merely examples and are not intended to limit the implementation of the embodiments of this application described and / or claimed herein.

[0071] The device 300 may include a processor 310, a memory 320, and a communication unit 330. These components communicate via one or more buses. Those skilled in the art will understand that the server structure shown in the figure does not constitute a limitation of the present invention. It may be a bus topology or a star topology, and may include more or fewer components than shown, or combine certain components, or have different component arrangements.

[0072] The memory 320 can be used to store execution instructions of the processor 310. The memory 320 can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic storage, flash memory, magnetic disk, or optical disk. When the execution instructions in the memory 320 are executed by the processor 310, the device 300 is able to perform some or all of the steps in the above method embodiments.

[0073] The processor 310 serves as the control center of the storage device, connecting various parts of the electronic device via various interfaces and lines. It executes software programs and / or modules stored in the memory 320, and calls data stored in the memory to perform various functions of the electronic device and / or process data. The processor can be composed of integrated circuits (ICs), such as a single packaged IC or multiple packaged ICs with the same or different functions connected together. For example, the processor 310 may consist only of a central processing unit (CPU). In this embodiment of the invention, the CPU may have a single processing core or include multiple processing cores.

[0074] The communication unit 330 is used to establish a communication channel, enabling the storage device to communicate with other devices. It can receive user data sent by other devices or send user data to other devices.

[0075] The present invention also provides a computer storage medium, wherein the computer storage medium may store a program, which, when executed, may include some or all of the steps provided in the embodiments of the present invention. The storage medium may be a magnetic disk, an optical disk, read-only memory (ROM), or random access memory (RAM), etc.

[0076] Those skilled in the art will clearly understand that the techniques in the embodiments of the present invention can be implemented using software plus necessary general-purpose hardware platforms. Based on this understanding, the technical solutions in the embodiments of the present invention, or the parts that contribute to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium such as a USB flash drive, a portable hard drive, a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk, or any other medium capable of storing program code. It includes several instructions to cause a computer device (which may be a personal computer, a server, or a second device, network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of the present invention.

[0077] The same or similar parts between the various embodiments in this specification can be referred to mutually. In particular, the device embodiments are basically similar to the method embodiments, so the description is relatively simple, and the relevant parts can be referred to the description in the method embodiments.

[0078] In the embodiments provided by this invention, it should be understood that the disclosed systems and methods can be implemented in other ways. For example, the system embodiments described above are merely illustrative. For instance, the division of modules is only a logical functional division, and in actual implementation, there may be other division methods. For example, multiple modules or components may be combined or integrated into another system, or some features may be ignored or not executed. Furthermore, the coupling or direct coupling or communication connection shown or discussed may be through some interfaces; the indirect coupling or communication connection between systems or modules may be electrical, mechanical, or other forms.

[0079] The modules described as separate components may or may not be physically separate. The components shown as modules may or may not be physical modules; that is, they may be located in one place or distributed across multiple network modules. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs.

[0080] In addition, the functional modules in the various embodiments of the present invention can be integrated into one processing module, or each module can exist physically separately, or two or more modules can be integrated into one module.

[0081] Although the present invention has been described in detail with reference to the accompanying drawings and preferred embodiments, the present invention is not limited thereto. Various equivalent modifications or substitutions can be made to the embodiments of the present invention by those skilled in the art without departing from the spirit and essence of the invention, and such modifications or substitutions should all be within the scope of the present invention. Any variations or substitutions that can be easily conceived by those skilled in the art within the technical scope disclosed in the present invention should also be covered within the protection scope of the present invention.

Claims

1. A method for supporting multi-flow data supply and demand interfacing, characterized in that, The method comprises the following steps: receiving a data requirement submitted by a demander, wherein the data requirement comprises at least a requirement content and one or more requirement information items; automatically checking the data requirement, and determining whether third-party intervention is needed for processing the data requirement based on preset decision rules after the data requirement passes the check; in response to determining that no third-party intervention is needed, directly distributing the data requirement to one or more target data providing departments for claiming and processing; in response to determining that third-party intervention is needed, routing the data requirement to a third-party coordination end, and performing aggregation or decomposition processing on the data requirement by the third-party coordination end, and distributing the processed data requirement to the target data providing department.

2. The method of claim 1, wherein, After the data requirement is claimed by the data providing department and the provision is confirmed, the method further comprises the following steps of data resource provision: associating the data requirement that has been confirmed to be provided with a specified data resource; providing the associated data resource to the demander.

3. The method of claim 1, wherein, Receiving a data requirement submitted by a demander comprises the following steps: providing a structured input interface through a requirement reporting module; receiving at least the following fields input by the demander in the interface: requirement name, requirement content, and one or more requirement information items in a standardized format; the requirement information item is in a standard data element format.

4. The method of claim 1, wherein, Automatically checking the data requirement comprises the following steps: performing basic integrity checking, including non-empty checking and format compliance checking on key fields in the requirement name, requirement content, and requirement information item; performing business rationality checking, including department authority checking according to the functional scope of the requirement submitting department, and / or comparing the current requirement with historical requirements to perform duplicate requirement detection; wherein, if the checking fails, a rejection correction operation is triggered, and if the checking passes, a subsequent process branch decision is triggered.

5. The method of claim 4, wherein, Determining whether third-party intervention is needed for processing the data requirement based on preset decision rules comprises the following steps: analyzing the data requirement to extract at least one requirement information item as a matching keyword; querying one or more responsible departments corresponding to each requirement information item in a predefined global data responsibility matrix; aggregating the query results and outputting a decision signal for process branching based on the aggregation results; if all requirement information items point to the same responsible department, a decision signal indicating direct distribution is outputted; if the requirement information items point to multiple different responsible departments, a decision signal indicating that third-party intervention is needed for decomposition is outputted; if any requirement information item does not match any responsible department in the global data responsibility matrix, a decision signal indicating that third-party intervention is needed for coordination is outputted.

6. The method of claim 1, wherein, Before the data requirement is aggregated or decomposed, the method further comprises the following steps: automatically identifying the data requirement to determine its processing type: if a text similarity algorithm is used to identify that the similarity with an existing requirement exceeds a threshold, it is determined that automatic aggregation processing is needed; if the requirement information items of the data requirement are identified to belong to multiple different departments based on the global data responsibility matrix, it is determined that automatic decomposition processing is needed; If the similarity of the data requirement to existing requirements does not exceed a threshold and the requirement information item does not belong to multiple different departments, it is determined to be a simple requirement that can be directly distributed.

7. The method of claim 6, wherein, The third party coordinates the aggregation or decomposition of the data requirement and distributes the processed data requirement to the target data providing department, including: If automatic aggregation processing is performed, the steps include: By calculating the text similarity between the current data requirement and existing requirements in the system, the current requirement is automatically merged into the same requirement group as the existing requirements with a similarity exceeding a preset threshold; Performing cluster analysis on all requirements in the requirement group and automatically generating a standardized aggregated requirement theme; Based on the global data responsibility matrix, one or more primary responsible departments are intelligently recommended for the aggregated requirement theme; The aggregated requirement theme is distributed to the recommended responsible departments; If automatic decomposition processing is performed, the steps include: Taking the requirement information item as the smallest unit, it is matched with the global data responsibility matrix to determine the corresponding responsible department for each data item; According to the matching result, the data requirement is automatically decomposed into multiple sub-requirements, each of which is associated with a target responsible department and the specific data items it needs to provide; The multiple sub-requirements are distributed in parallel to the respective corresponding target data providing departments.

8. A system supporting multi-flow data supply and demand interfacing, characterized in that, It includes: A requirement receiving module for receiving data requirements submitted by a demander, the data requirements including at least requirement content and one or more requirement information items; A requirement coordination module for automatically checking the data requirements, and based on preset decision rules, determining whether third-party intervention is needed for processing the data requirements after passing the check; A direct distribution module for directly distributing the data requirements to one or more target data providing departments for claiming and processing in response to determining that third-party intervention is not needed; An intervention processing module for routing the data requirements to a third-party coordination end in response to determining that third-party intervention is needed, and processing the data requirements by the third-party coordination end, and distributing the processed data requirements to the target data providing department.

9. A device that supports multi-process data supply and demand docking, characterized in that, It includes: A memory for storing a program supporting multi-process data supply and demand docking; A processor for executing the program supporting multi-process data supply and demand docking to realize the steps of the method supporting multi-process data supply and demand docking according to any one of claims 1-7.

10. A computer readable storage medium storing a computer program, characterized in that, The readable storage medium has a program supporting multi-process data supply and demand docking stored thereon, and the program supporting multi-process data supply and demand docking is executed by the processor to realize the steps of the method supporting multi-process data supply and demand docking according to any one of claims 1-7.

Images