Collaborative processing method and system for cross-departmental data
By building cross-departmental virtual data tables and preset cache systems through central servers, the cross-departmental data query process is optimized, the problem of low efficiency in cross-departmental data collaborative processing is solved, and a logically unified data view and efficient data transmission are achieved.
Patent Information
- Application Number
- CN202511000197.3
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- Filing Date
- 2025-07-21
- Publication Date
- 2025-09-12
- Estimated Expiration
- 2045-07-21
AI Technical Summary
The efficiency of cross-departmental data collaboration is low. The current methods rely on offline letter sending or online approval processes, which are cumbersome and time-consuming, resulting in low data collaboration efficiency.
By building cross-departmental virtual data tables through the central server and combining the preset cache system and target service scheduling strategy, the data query process is optimized to achieve a logically unified data view and efficient data transmission.
Without physical data migration, it breaks down departmental data barriers, improves cross-departmental data query efficiency, shortens response time, and enhances overall query efficiency.
Smart Images

Figure CN120509854B_ABST
Abstract
Description
Technical Field
[0001] The present application belongs to the field of data collaboration technology, and in particular relates to a method and system for collaborative processing of cross-departmental data. Background Art
[0002] With the continuous development of informatization, technologies such as big data and artificial intelligence are becoming increasingly important in cross-departmental collaboration. When handling complex business operations, cross-departmental data collaboration is often required between different departments of multiple units.
[0003] However, data barriers and information silos are prevalent between different units, resulting in low efficiency in cross-departmental data collaboration. Specifically, when a data-demanding department needs to retrieve non-public internal data from another data-holding department, existing methods typically rely on offline correspondence or online approval processes, which are cumbersome and time-consuming, reducing the efficiency of cross-departmental data collaboration. Summary of the Invention
[0004] In view of this, an embodiment of the present application provides a method and system for collaborative processing of cross-departmental data to solve the technical problem of low query efficiency of existing cross-departmental data query methods.
[0005] In a first aspect, an embodiment of the present application provides a method for collaboratively processing cross-departmental data, including:
[0006] When an application server of any business participating department receives a cross-department collaboration request from a user terminal of the department, it sends the cross-department collaboration request to the central server;
[0007] The central server determines a target service scheduling strategy based on the cross-departmental collaborative request and the service capability vectors of each atomic service; the target service scheduling strategy is used to describe the optimal service combination and optimal service call sequence for executing the cross-departmental collaborative request;
[0008] The central server sends corresponding service requests to the application servers of the business participating departments where the target atomic services in the optimal service combination are located in sequence according to the optimal service calling order;
[0009] In the case where the target atomic service includes a data query service, the application server of the business participating department where the data query service is located queries, based on the target query request from the central server, whether there is a target query result corresponding to the target query request in the preset cache system;
[0010] In the case that the target query result does not exist in the preset cache system, the application server of the business participating department where the data query service is located sends the target query request to the central server, so that the central server determines the sub-query request for the source data table of one or more business participating departments to be queried according to the metadata conversion rule of the target logical field name corresponding to the target query request in the pre-generated cross-department virtual data table, and sends the corresponding sub-query request to the application server of each business participating department to be queried; the cross-department virtual data table is constructed by the central server based on the source data tables of all the business participating departments;
[0011] The central server integrates the sub-query results returned by the application servers of the business participating departments to be queried, obtains the target query result corresponding to the target query request, and returns the target query result to the application server that initiated the cross-department collaboration request.
[0012] In an optional implementation of the first aspect, before the central server determines the target service scheduling strategy according to the cross-department collaboration request and the service capability vectors of each atomic service, the method further includes:
[0013] The central server constructs a feature space dictionary of the service capability vector; the feature space dictionary includes n Functional label feature items, m Quality indicator feature items and s constraint condition feature items; the dimension of the feature space dictionary is X , X = n + m + s ;
[0014] For each of the atomic services, the central server calculates the score of the atomic service relative to each feature item in the feature space dictionary, and determines the vector composed of the score values of the atomic service relative to all the feature items as the service capability vector of the atomic service.
[0015] In an optional implementation of the first aspect, for each of the atomic services, the central server calculates a score value of the atomic service relative to each feature item in the feature space dictionary, including:
[0016] For each of the atomic services, the central server calculates the term frequency-inverse document frequency of each of the function label feature items in the feature space dictionary relative to the atomic service, and determines the normalized term frequency-inverse document frequency corresponding to each of the function label feature items as the score value of the atomic service relative to each of the function label feature items;
[0017] For each of the atomic services, the central server normalizes the actual value of each of the quality indicator feature items of the atomic service in the feature space dictionary to obtain a score value of the atomic service relative to each of the quality indicator feature items;
[0018] For each of the atomic services, when the atomic service needs to be constrained by the constraint-type feature item in the feature space dictionary, the central server determines that the score value of the atomic service relative to the constraint-type feature item is 1; when the atomic service does not need to be constrained by the constraint-type feature item in the feature space dictionary, the central server determines that the score value of the atomic service relative to the constraint-type feature item is 0.
[0019] In an optional implementation of the first aspect, for each of the atomic services, the central server calculates the term frequency-inverse document frequency of each of the function tag feature items in the feature space dictionary relative to the atomic service, including:
[0020] The central server calculates the word frequency of the keywords corresponding to each of the function tag feature items in the function description document of each of the atomic services using a first formula; the first formula is:
[0021] ;
[0022] in, TF i,j For the i The keywords corresponding to the functional label feature items are in j The frequency of words in the functional description document of the atomic service, N i,j For the i The keywords corresponding to the functional label feature items are in j The number of times the atomic service appears in the functional description document, N all The keywords corresponding to all the functional label feature items are in the j The total number of times the atomic service appears in the functional description document, 1≤ i ≤ n, 1≤ j ≤| D |, i and j is an integer, | D |The total number of services for the atom;
[0023] The central server calculates the inverse document frequency of the keyword corresponding to each of the function tag features relative to the function description documents of all the atomic services using a second formula; the second formula is:
[0024] ;
[0025] in, IDF i For the i The inverse document frequency of the keywords corresponding to the function label feature items relative to the function description documents of all the atomic services, log() is a logarithmic operation, |{ j : t i ∈ d j}|To include the i the number of function description documents containing the keywords corresponding to the function tag feature items;
[0026] For each of the function tag feature items, the central server determines the product of the word frequency of the keyword corresponding to the function tag feature item and the inverse document frequency as the word frequency-inverse document frequency of the function tag feature item relative to the atomic service.
[0027] In an optional implementation of the first aspect, sending the corresponding sub-query request to the application server of each business participating department to be queried includes:
[0028] The central server determines the target transmission channel based on the sensitive attributes of the sub-query result requested by the sub-query request and the target scenario targeted by the cross-departmental collaboration request, and sends a corresponding sub-query request carrying the target transmission channel to the application server of each business participating department to be queried, so that the application server of each business participating department to be queried returns the corresponding sub-query result to the central server through the corresponding target transmission channel; the target scenario includes a real-time query scenario or a batch analysis scenario.
[0029] In an optional implementation of the first aspect, the sensitive attribute includes sensitive or non-sensitive; correspondingly, the central server determines the target transmission channel based on the sensitive attribute of the target logical field name and the target scenario targeted by the cross-department collaboration request, including:
[0030] In the case where the sensitive attribute is sensitive and the target scenario is a real-time query scenario, the central server determines the dedicated encrypted channel between the application server of the business participating department to be queried and the central server as the target transmission channel, obtains the health attribute of the dedicated encrypted channel in real time, and when it is determined that the dedicated encrypted channel is in an abnormal state according to the health attribute, determines the backup encrypted channel between the application server of the business participating department to be queried and the central server as the target transmission channel;
[0031] In the case where the sensitive attribute is sensitive and the target scenario is a batch analysis scenario, the central server uses the dedicated encrypted channel and the target encrypted channel between the application server of the business participating department to be queried and the preset sandbox as the target transmission channel;
[0032] When the sensitive attribute is non-sensitive and the target scenario is a real-time query scenario, the central server determines the first public transmission channel between the application server of the business participating department to be queried and the central server as the target transmission channel;
[0033] When the sensitive attribute is non-sensitive and the target scenario is a batch analysis scenario, the central server determines the first public transmission channel and the second public transmission channel between the application server of the business participating department to be queried and the preset sandbox as the target transmission channel.
[0034] In an optional implementation of the first aspect, the central server determines a target service scheduling strategy based on the cross-department collaboration request and the service capability vectors of each atomic service, including:
[0035] The central server determines a request vector of the cross-departmental collaborative request and calculates similarity between the request vector and a service capability vector of each of the atomic services; the dimension of the request vector is the same as the dimension of the service capability vector;
[0036] The central server determines the atomic service having a similarity with the request vector greater than or equal to a first similarity threshold as a candidate atomic service;
[0037] The central server randomly combines multiple different original service scheduling strategies from the candidate atomic services, and calculates the total response time and total resource consumption score value of each of the original service scheduling strategies, and determines the original service scheduling strategy whose total response time is less than the preset duration and the total resource consumption score value is less than the preset score value as the target service scheduling strategy.
[0038] In an optional implementation of the first aspect, the method further includes:
[0039] In the case where the target atomic service includes a data update service, the application service of the business participating department where the data update service is located receives the data update request from the central server, executes the data update request, and records an execution log of the data update request;
[0040] If the data update request is successfully executed, the application server of the business participating department where the data update service is located returns a first message to the central server indicating that the data update service is ready; if the data update request fails to be executed, the application server of the business participating department where the data update service is located returns a second message to the central server indicating that the data update service has failed.
[0041] When all application servers of the business participating departments where the data update service is located return the first message, the central server sends an update submission request to all application servers of the business participating departments where the data update service is located, so that all application servers of the business participating departments where the data update service is located save the execution results corresponding to the data update request;
[0042] In the case that at least one application server of the business participating department where the data update service is located returns the second message, the central server sends a rollback request to all application servers of the business participating departments where the data update service is located, so that all application servers of the business participating departments where the data update service is located cancel the execution result corresponding to the data update request according to the execution log.
[0043] In an optional implementation of the first aspect, the method further includes:
[0044] For any target atomic service included in the target service scheduling strategy, the central server counts a first number of timeout errors, a second number of exception errors, and a third number of business errors generated by the target atomic service within a preset time period, and counts a fourth number of total requests received by the target atomic service within the preset time period, and determines the ratio of the sum of the first number, the second number, and the third number to the fourth number as the call error rate of the target atomic service;
[0045] When the call error rate of the target atomic service is greater than the preset error rate threshold, the central server does not send the corresponding service request to the target atomic service, and returns the corresponding service request to the application server that initiated the cross-departmental collaboration request, so that the application server that initiated the cross-departmental collaboration request obtains the service result corresponding to the service request from the preset cache system.
[0046] In a second aspect, an embodiment of the present application provides a cross-departmental data collaborative processing system, comprising a central server, an edge node server, and multiple application servers; each of the application servers is deployed in a business participating department; the central server and the edge node server are respectively connected to the multiple application servers, and each application server is connected to one or more user terminals of the department;
[0047] The application server is used to send the cross-department collaboration request to the central server when receiving the cross-department collaboration request from the user terminal of the department;
[0048] The central server is used to determine a target service scheduling strategy based on the cross-departmental collaborative request and the service capability vectors of each atomic service; the target service scheduling strategy is used to describe the optimal service combination and optimal service call sequence for executing the cross-departmental collaborative request;
[0049] The central server is further configured to send corresponding service requests to the application servers of the business participating departments where the target atomic services in the optimal service combination are located in sequence according to the optimal service calling sequence;
[0050] In the case where the target atomic service includes a data query service, the application server of the business participating department where the data query service is located is used to query whether there is a target query result corresponding to the target query request in the preset cache system according to the target query request from the central server;
[0051] The application server of the business participating department where the data query service is located is also used to, when the target query result does not exist in the preset cache system, send the target query request to the central server by the application server of the business participating department where the data query service is located, so that the central server determines the sub-query request for the source data table of one or more business participating departments to be queried according to the metadata conversion rule of the target logical field name corresponding to the target query request in the pre-generated cross-departmental virtual data table, and sends the corresponding sub-query request to the application server of each business participating department to be queried; the cross-departmental virtual data table is constructed by the central server based on the source data tables of all the business participating departments;
[0052] The central server is also used to integrate the sub-query results returned by the application servers of each of the business participating departments to be queried, obtain the target query result corresponding to the target query request, and return the target query result to the application server that initiated the cross-department collaboration request.
[0053] Implementing the cross-departmental data collaborative processing method and system provided in the embodiments of the present application has the following beneficial effects:
[0054] The collaborative processing method for cross-departmental data provided in the embodiment of the present application can provide a logically unified and physically dispersed data view for all business participating departments by constructing a cross-departmental virtual data table based on the source data table of each business participating department. In this way, the data barriers between departments can be broken down without migrating the physical data table, thereby improving the query efficiency of cross-departmental data. In addition, by configuring a secondary preset cache system, when a target query result corresponding to a target query request exists in the preset cache system, the target query result is obtained from the preset cache system first, thereby further shortening the overall response time of cross-departmental collaborative requests and further improving the query efficiency of cross-departmental data. BRIEF DESCRIPTION OF THE DRAWINGS
[0055] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following briefly introduces the drawings required for use in the embodiments or descriptions of the prior art. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.
[0056] Figure 1 A schematic diagram of the structure of a cross-departmental data collaborative processing system provided in an embodiment of the present application;
[0057] Figure 2 A schematic flow chart of a method for collaboratively processing cross-departmental data provided in an embodiment of the present application;
[0058] Figure 3 A schematic flowchart of a method for collaboratively processing cross-departmental data provided in another embodiment of the present application;
[0059] Figure 4 This is a flowchart for the specific implementation of S302 in a method for collaborative processing of cross-departmental data provided in an embodiment of the present application;
[0060] Figure 5 This is a flowchart for the specific implementation of S202 in a method for collaborative processing of cross-departmental data provided in an embodiment of the present application;
[0061] Figure 6 A schematic flowchart of a method for collaboratively processing cross-departmental data provided in yet another embodiment of the present application;
[0062] Figure 7 A schematic flowchart of a method for collaborative processing of cross-departmental data provided in yet another embodiment of the present application. DETAILED DESCRIPTION
[0063] The following embodiments are only used to more clearly illustrate the technical solutions of the present application and are therefore only used as examples and are not intended to limit the scope of protection of the present application.
[0064] In the description of the embodiments of the present application, the technical terms "include", "comprise", "have" and any variations thereof mean "including but not limited to", unless otherwise specifically emphasized. In the description of the embodiments of the present application, unless otherwise specified, the technical term "multiple" refers to two or more than two, and the technical terms "at least one" and "one or more" refer to one, two or more. The technical terms "first" and "second" are only used to distinguish different objects, and cannot be understood as indicating or implying relative importance or implicitly indicating the number, specific order or primary and secondary relationship of the indicated technical features. The technical term "and / or" is merely a description of the association relationship of associated objects, indicating that there can be three relationships, such as A and / or B, which can mean: A exists alone, A and B exist at the same time, and B exists alone. In addition, the character " / " in this article generally indicates that the previous and subsequent associated objects are in an "or" relationship.
[0065] The present application embodiment first provides a cross-departmental data collaborative processing system. Figure 1 , is a schematic diagram of the structure of a cross-departmental data collaborative processing system provided by an embodiment of the present application. Figure 1 As shown, the cross-departmental data collaborative processing system may include a central server, a preset sandbox, an edge node server, and multiple application servers deployed in various business participating departments.
[0066] Among them, the central server, edge node server and preset sandbox are respectively connected to multiple application servers, and each application server is connected to one or more user terminals of the department.
[0067] A dedicated encrypted channel, a backup encrypted channel, and a first public transmission channel can be established between the central server and each application server. A target encrypted channel and a second public transmission channel can be established between the pre-set sandbox and each application server. The dedicated encrypted channel, backup encrypted channel, and target encrypted channel can be used to transmit sensitive data, while the first and second public transmission channels can be used to transmit non-sensitive data.
[0068] Optionally, the central server may be a server cluster consisting of multiple servers.
[0069] Optionally, the edge node server may also be a server cluster consisting of multiple servers.
[0070] It should be noted that, for the specific functions of the central server, edge node server and each application server, reference can be made to the relevant description in the subsequent method embodiments, which will not be described in detail here.
[0071] The embodiment of the present application also provides a method for collaborative processing of cross-departmental data. Figure 2 This is a schematic flow chart of a method for collaboratively processing cross-departmental data provided in an embodiment of the present application. Figure 2 As shown, the collaborative processing method for cross-departmental data may include S201 to S206, which are described in detail as follows:
[0072] S201: When an application server of any business participating department receives a cross-department collaboration request from a user terminal of the department, the application server sends the cross-department collaboration request to the central server.
[0073] Among them, business participating departments refer to departments that have collaborative relationships in one or more business scenarios.
[0074] For example, in a business scenario involving multi-party collaboration, there is a close business collaboration relationship between multiple departments (such as the sponsoring department, collaborative department A, and collaborative department B). For example, in the process of handling a core business, the sponsoring department may need to retrieve the historical business processing records of a related entity from collaborative department A in order to comprehensively evaluate the business situation; if the business situation is more complicated, it may also be necessary to retrieve the internal appraisal materials and / or technical analysis reports generated by collaborative department B in the previous process. When the core business processing is completed, the sponsoring department will synchronize the final processing results to collaborative department A and collaborative department B, so that all parties can synchronously update the processing status of the corresponding tasks in their business systems. Therefore, the sponsoring department, collaborative department A, and collaborative department B are the business participating departments in this specific business scenario.
[0075] Cross-departmental collaboration requests refer to service requests that require the collaborative completion of multiple business departments. For example, cross-departmental collaboration requests may include cross-departmental query requests and cross-departmental update requests. For example, a cross-departmental query request may include a request from the sponsoring department to query historical business records. A cross-departmental update request may include a request from the sponsoring department to update business processing results.
[0076] S202, the central server determines a target service scheduling strategy based on the cross-departmental collaborative request and the service capability vectors of each atomic service; the target service scheduling strategy is used to describe the optimal service combination and optimal service calling sequence for executing the cross-departmental collaborative request.
[0077] Each atomic service refers to all atomic services deployed in the application servers of each business department. Each atomic service can be used to implement a single function, and different atomic services can be used to implement different functions. In practice, the application servers of different business departments can have atomic services with different functions, or atomic services with the same functions. The functions of the atomic services deployed in each business department's application server can be determined based on the department's business functions.
[0078] For example, the application server of the sponsoring department can be deployed with atomic services such as feature comparison service and business status update service. The application server of collaborative department A can be deployed with atomic services such as professional document retrieval service and compliance document retrieval service. The application server of collaborative department B can be deployed with atomic services such as restricted data access service and core document transfer service.
[0079] In actual applications, the maximum number of input parameters of each atomic service can be configured to be less than or equal to a first number, and the maximum response time of each atomic service can be configured to be less than or equal to a first duration. For example, the first number can be 5, and the first duration can be 500 milliseconds (ms).
[0080] The embodiment of the present application is to split the complex business functions of the entire system into one or more atomic services, so that the function of each atomic service is more single and clear, so that developers can maintain the atomic services without affecting other atomic services, thereby reducing the maintenance cost of the entire system. Moreover, the embodiment of the present application is to atomize the functions of the entire system, so that the system can flexibly configure the functions of the atomic services according to changes in business needs, thereby improving the flexibility of the system function configuration. In addition, since each atomic service can be deployed and operated independently, the system can allocate resources only for the atomic services actually used, thereby reducing the waste of system resources and improving overall resource utilization.
[0081] Optionally, when the central server is a server cluster, a blockchain can be deployed in the central server. The blockchain can be configured with a zero-knowledge proof module and a smart contract, etc. Based on this, after receiving a cross-departmental collaboration request, the central server can call the zero-knowledge proof module based on the bilinear pairing construction to perform non-interactive verification on the decentralized identifier (DID) of the user who initiated the cross-departmental collaboration request. After the user identity verification is passed, the central server can also verify the user's operation authority to execute the cross-departmental collaboration request through the smart contract deployed on the blockchain. If the user has the corresponding operation authority, the central server will then calculate the target service scheduling strategy based on the cross-departmental collaboration request and the service capability vector of each atomic service, which can improve data security.
[0082] The capability vector of the atomic service can be used to describe the specific function of the atomic service. The service capability vectors of atomic services with different functions are different. In actual applications, the service capability vectors of each atomic service can be determined by the central server before executing S202. Based on this, Figure 3 As shown, before S202, the cross-departmental data collaborative processing method may further include S301 to S302, which are described in detail as follows:
[0083] S301, the central server constructs a feature space dictionary of the service capability vector; the feature space dictionary includes n Functional label feature items, m Quality indicator feature items and s constraint-type feature items; the dimension of the feature space dictionary is X , X = n + m + s .
[0084] Among them, the function label type feature items can include the function labels of all atomic services.
[0085] Quality indicator feature items can be used to measure the performance of atomic services.
[0086] Constraint feature items can consist of all user permissions required for the operation of atomic services.
[0087] Optionally, the central server constructs a feature space dictionary of the service capability vector, which may specifically include steps 1.1 to 1.3, as detailed below:
[0088] In step 1.1, the central server extracts the function label of each atomic service respectively, and determines all the extracted non-repeated function labels as the function label class feature items in the feature space dictionary.
[0089] Among them, the function label of the atomic service can be used to describe the specific function of the atomic service.
[0090] For example, the application server of the sponsoring department can be deployed with a feature comparison service and a business status update service. The functional label of the feature comparison service can be "feature comparison", and the functional label of the business status update service can be "business status update". The application server of collaborative department A can be deployed with a professional document retrieval service and a compliance document retrieval service. The functional label of the professional document retrieval service can be "professional document retrieval", and the functional label of the compliance document retrieval service can be "compliance document retrieval". The application server of collaborative department B can be deployed with a restricted data access service and a core document circulation service. The functional label of the restricted data access service can be "restricted data access", and the functional label of the core document circulation service can be "core document circulation". Based on this, the central server can determine "feature comparison", "business status update", "professional document retrieval", "compliance document retrieval", "restricted data access", and "core document circulation" as functional label feature items in the feature space dictionary.
[0091] In step 1.2, the central server determines the response time and throughput as quality indicator feature items in the feature space dictionary.
[0092] Response time refers to the time it takes for an atomic service to receive a request, process it, and return the result. Response time can be used to measure how quickly an atomic service processes a single request.
[0093] Throughput refers to the number of requests that an atomic service can successfully process per unit time. Throughput can be used to measure the processing capacity of an atomic service (i.e., how well it can withstand the pressure of concurrent access).
[0094] In step 1.3, the central server obtains the user permissions required for the operation of each atomic service, and determines all the non-repeated user permissions obtained as constraint condition feature items in the feature space dictionary.
[0095] For example, assuming that the user permissions required for the operation of the restricted data retrieval service are "business reviewer" and the user permissions required for the operation of the feature comparison service are "senior approver", the central server can determine "business reviewer" and "senior approver" as constraint condition feature items in the feature space dictionary.
[0096] It should be noted that the dimension of the feature space dictionary defines the dimension of the capability vector of the atomic service, that is, the dimension of the service capability vector of each atomic service is X .
[0097] S302, for each atomic service, the central server calculates the score of the atomic service relative to each feature item in the feature space dictionary, and determines the vector composed of the score values of the atomic service relative to all feature items as the service capability vector of the atomic service.
[0098] For example, the central server may use different calculation methods to calculate the score values of the atomic service relative to different types of feature items in the feature space dictionary. Based on this, S302 may specifically include the following: Figure 4 S3021 to S3023 shown are described in detail as follows:
[0099] S3021, for each atomic service, the central server calculates the word frequency-inverse document frequency of each function label feature item in the feature space dictionary relative to the atomic service, and determines the normalized word frequency-inverse document frequency corresponding to each function label feature item as the score value of the atomic service relative to each function label feature item.
[0100] The term frequency-inverse document frequency corresponding to each function label feature item is the term frequency-inverse document frequency of each function label feature item relative to the atomic service.
[0101] Specifically, the central server can calculate the term frequency-inverse document frequency of each function label feature item in the feature space dictionary relative to the atomic service through steps 2.1 to 2.3, as detailed below:
[0102] In step 2.1, the central server calculates the word frequency of the keywords corresponding to each function tag feature item in the function description document of each atomic service using the first formula; the first formula is:
[0103] ;
[0104] in, TF i,j For the i The keywords corresponding to the functional label feature items are in j The word frequency in the functional description document of each atomic service, N i,j For the i The keywords corresponding to the functional label feature items are in j The number of times an atomic service appears in the functional description document, N all The keywords corresponding to all functional label feature items are in the j The total number of times an atomic service appears in the functional description document, 1≤ i ≤ n , 1≤ j ≤|D |, i and j is an integer, | D |The total number of atomic services (that is, the total number of functional description documents).
[0105] In step 2.2, the central server calculates the inverse document frequency of the keyword corresponding to each function tag feature relative to the function description documents of all atomic services using the second formula; the second formula is:
[0106] ;
[0107] in, IDF i For the i The inverse document frequency of the keywords corresponding to the function label feature items relative to the function description documents of all atomic services, log() is the logarithmic operation, |{ j : t i ∈ d j}|To include the i The number of function description documents of keywords corresponding to the function label feature items.
[0108] Step 2.3: For each function tag feature item, the central server multiplies the word frequency and inverse document frequency of the keyword corresponding to the function tag feature item to determine the word frequency-inverse document frequency of the function tag feature item relative to the atomic service.
[0109] For example, i The functional label feature item is relative to the j Term frequency-inverse document frequency of atomic services TF - IDF i,j It can be expressed as TF - IDF i,j = TF i,j × IDF i .
[0110] It can be understood that the greater the word frequency-inverse document frequency of the function label feature item relative to the atomic service, the more important the function label feature item is relative to the atomic service.
[0111] Optionally, after calculating the term frequency-inverse document frequency of each functional label feature item in the feature space dictionary relative to each atomic service, the central server can normalize each term frequency-inverse document frequency according to the maximum term frequency-inverse document frequency and the minimum term frequency-inverse document frequency among all term frequency-inverse document frequencies, so as to normalize all term frequency-inverse document frequencies to the interval [0,1].
[0112] S3022: For each atomic service, the central server normalizes the actual value of each quality indicator feature item of the atomic service in the feature space dictionary to obtain the score value of the atomic service with respect to each quality indicator feature item.
[0113] Optionally, for each atomic service, the central service server may determine the historical average value of each quality indicator feature item of the atomic service in the feature space dictionary as the actual value of each quality indicator feature item of the atomic service. For example, assuming that the historical average value of the infringement feature comparison service for the quality indicator feature item of response time is 300ms, and the historical average value of the quality indicator feature item of throughput is 5, the central server may determine the actual value of the infringement feature comparison service for the quality indicator feature item of response time as 300ms, and the actual value of the infringement feature comparison service for the quality indicator feature item of throughput as 5.
[0114] It is understandable that since the magnitude of the actual values of each atomic service for different quality indicator feature items may vary, after the central server obtains the actual value of each atomic service for each quality indicator feature item in the feature space dictionary, it can normalize the actual value of each atomic service for each quality indicator feature item based on the maximum actual value and minimum actual value of all atomic services for that quality indicator feature item, so that the actual values of all atomic services for that quality indicator feature item are normalized to the interval [0,1]. For example, the central server can normalize the actual value of each atomic service for the quality indicator feature item response time based on the maximum actual value and minimum actual value of all atomic services for that quality indicator feature item response time; the central server can also normalize the actual value of each atomic service for the quality indicator feature item throughput based on the maximum actual value and minimum actual value of all atomic services for that quality indicator feature item throughput.
[0115] S3023, for each atomic service, when the atomic service needs to be constrained by the constraint class feature item in the feature space dictionary, the central server determines that the score value of the atomic service relative to the constraint class feature item is 1; when the atomic service does not need to be constrained by the constraint class feature item in the feature space dictionary, the central server determines that the score value of the atomic service relative to the constraint class feature item is 0.
[0116] For example, assume that the constraint condition feature items in the feature space dictionary include "business reviewer," "senior approver," and "technical assessor." If the user permission required to run the feature comparison service is "business reviewer," the central server can set the score of the feature comparison service for both the "senior approver" and "technical assessor" constraint condition feature items to 0, and set the score of the feature comparison service for the "business reviewer" constraint condition feature item to 1.
[0117] Optionally, after the central server determines the service capability vector of each atomic service, it may store the service capability vectors of all atomic services in a local memory for subsequent use.
[0118] Optionally, S202 may specifically include: Figure 5 The S2021~S2023 shown are detailed as follows:
[0119] S2021, the central server determines the request vector of the cross-departmental collaborative request and calculates the similarity between the request vector and the service capability vector of each atomic service; the dimension of the request vector is the same as the dimension of the service capability vector.
[0120] Optionally, the central server may determine the score value of the cross-departmental collaborative request relative to each feature item in the feature space dictionary, and determine the vector composed of the score values of the cross-departmental collaborative request relative to all feature items in the feature space dictionary as the request vector of the cross-departmental collaborative request.
[0121] It should be noted that the specific method of determining the score value of the cross-departmental collaborative request relative to each feature item in the feature space dictionary is the same as the method of calculating the score value of the atomic service relative to each feature item in the feature space dictionary in the above S302. Therefore, for the specific method of determining the score value of the cross-departmental collaborative request relative to each feature item in the feature space dictionary, please refer to the relevant description in the above S302 and will not be repeated here.
[0122] For example, the similarity may be cosine similarity. The value range of cosine similarity may be [-1, 1]. The closer the cosine similarity between the request vector of the cross-departmental collaborative request and the service capability vector of a certain atomic service is to 1, the more relevant the cross-departmental collaborative request is to the atomic service.
[0123] S2022: The central server determines an atomic service whose similarity to the request vector is greater than or equal to a first similarity threshold as a candidate atomic service.
[0124] Exemplarily, when the similarity is cosine similarity, since the maximum value of cosine similarity is 1, the first similarity threshold may be less than 1, for example, may be 0.9.
[0125] Optionally, there may be one or more candidate atomic services.
[0126] S2023, the central server randomly combines multiple different original service scheduling strategies from the candidate atomic services, and calculates the total response time and total resource consumption score of each original service scheduling strategy, and determines the original service scheduling strategy whose total response time is less than the preset duration and whose total resource consumption score is less than the preset score as the target service scheduling strategy.
[0127] It should be noted that each original service scheduling strategy includes at least one candidate atomic service. The types or calling orders of the candidate atomic services in different original service scheduling strategies are different.
[0128] Optionally, when the original service scheduling policy includes only one candidate atomic service, the central server may determine the response time and resource consumption score of the candidate atomic service as the total response time and total resource consumption score of the original service scheduling policy, respectively. For example, the resource consumption score of the candidate atomic service may be the sum of the average central processing unit (CPU) consumption rate and the average memory consumption rate of the candidate atomic service during runtime.
[0129] Optionally, if the original service scheduling policy includes multiple candidate atomic services, the central server may calculate the sum of the response times and the sum of the network delays of all atomic services in the original service scheduling policy, perform a sum operation on the sum of the response times and the sum of the network delays, and determine the resulting value as the total response time of the original service scheduling policy. In addition, the central server may calculate the total resource consumption score of the original service scheduling policy using a third formula; the third formula is:
[0130] ;
[0131] in,C total is the total resource consumption score of the original service scheduling policy. W cpu is the CPU weight coefficient, C cpu(k) The original service scheduling strategy k The average CPU consumption rate of candidate atomic services during operation, W mem is the memory weight coefficient, C mem(k) The original service scheduling strategy k The average memory consumption rate of candidate atomic services during runtime, T service(k) For the k The response time of an atomic service, M is the number of atomic services included in the original service scheduling strategy, 1≤ k ≤ M , k is an integer.
[0132] It should be noted that the total resource consumption score of the original service scheduling strategy C total The higher the value, the greater the pressure on the system hardware caused by the original service scheduling strategy; the total resource consumption score of the original service scheduling strategy C total The lower the value, the less pressure the original service scheduling policy puts on the system hardware.
[0133] Exemplarily, the above-mentioned preset duration and preset score value can be set according to actual conditions.
[0134] S203: The central server sends corresponding service requests to the application servers of the business participating departments where the target atomic services in the optimal service combination are located in sequence according to the optimal service calling order.
[0135] Optionally, when the target service scheduling strategy includes only one target atomic service, the central server may directly identify the cross-department collaboration request as a service request for the target atomic service, and send the cross-department collaboration request to the application server of the business participating department where the target atomic service is located. After receiving the cross-department collaboration request, the application server of the business participating department where the target atomic service is located may call the target atomic service to execute the cross-department collaboration request, obtain the target execution result corresponding to the target atomic service, and return the target execution result to the central server.
[0136] Optionally, when the target service scheduling strategy includes multiple target atomic services, the central server can determine the service requests for each target atomic service separately based on the cross-departmental collaboration request, and send corresponding service requests to the application servers of the business participating departments where each target atomic service is located in accordance with the optimal service call order.
[0137] It's understandable that some target atomic services in the target service scheduling strategy may require the execution results of the previous target atomic service as input data when executing their corresponding service requests. For these target atomic services, the central server sends the corresponding service requests to the application servers of the business participating departments where these atomic services are located, and also sends the execution results of the previous target atomic service to the application servers of the business participating departments where these atomic services are located.
[0138] It's also understandable that some target atomic services in the target service scheduling strategy may not require the execution results of the previous target atomic service as input data when executing their corresponding service requests. For these atomic services, the central server only sends the corresponding service requests to the application servers of the business participating departments where these atomic services are located.
[0139] After receiving the corresponding service request, the application server of each business participating department where the target atomic service is located can call the target atomic service to execute the corresponding service request, obtain the execution result corresponding to the service request, and return the execution result corresponding to the service request to the central server. The central server can integrate the execution results corresponding to all target atomic services to obtain the target execution result corresponding to the cross-departmental collaboration request, and return the target execution result to the application server that initiated the cross-departmental collaboration request.
[0140] S204, when the target atomic service includes a data query service, the application server of the business participating department where the data query service is located queries the preset cache system for a target query result corresponding to the target query request according to the target query request from the central server.
[0141] In some application scenarios, if the target atomic service includes a data query service, the service request sent by the central server to the application server of the business participating department where the data query service is located can be a target query request. Based on this, the application server of the business participating department where the data query service is located can call the data query service to execute the target query request and obtain the target query result.
[0142] It is understood that to improve data query efficiency, upon receiving a target query request, the application server of the business participating department where the data query service is located may first query the preset cache system to see whether there is a target query result corresponding to the target query request. The preset cache system may include a local cache deployed in the application server and a distributed cache deployed in the edge node server.
[0143] It is also understandable that, in order to reduce the risk of sensitive data leakage, the preset cache system may only cache non-sensitive data. Based on this, S204 may specifically include steps 3.1 to 3.3, which are detailed as follows:
[0144] In step 3.1, the application server of the business participating department where the data query service is located checks whether there is a target query result corresponding to the target query request in the local cache after determining that the target query result requested by the target query request does not contain sensitive data.
[0145] Optionally, if the target query result exists in the local cache of the application server of the business participating department where the data query service is located, the application server of the business participating department where the data query service is located can obtain the target query result from its local cache and return the target query result to the central server.
[0146] Optionally, when the target query result does not exist in the local cache of the application server of the business participating department where the data query service is located, the application server of the business participating department where the data query service is located may execute step 3.2.
[0147] In step 3.2, if the target query result does not exist in the local cache, the application server of the business participating department where the data query service is located sends a target query request to the edge node server to query whether the target query result exists in the distributed cache in the edge node server.
[0148] Optionally, if the target query result exists in the distributed cache of the edge node server, the edge node server may send the target query result to the application server of the business participating department where the data query service is located. The application server of the business participating department where the data query service is located may return the target query result to the central server.
[0149] Optionally, if the target query result does not exist in the distributed cache of the edge node server, the edge node server may send a first prompt message to the application server of the business participating department where the data query service is located. The first prompt message may be used to indicate that the target query result does not exist in the distributed cache of the edge node server. In this case, the application server of the business participating department where the data query service is located may execute step 3.3.
[0150] In step 3.3, when the target result does not exist in the distributed cache, the application server of the business participating department where the data query service is located determines that the target query result does not exist in the preset cache system.
[0151] Optionally, when determining that the target query result requested by the target query request contains sensitive data, the application server of the business participating department where the data query service is located may directly determine that the target query result does not exist in the preset cache system.
[0152] S205. When the target query result does not exist in the preset cache system, the application server of the business participating department where the data query service is located sends a target query request to the central server, so that the central server determines the sub-query request for the source data table of one or more business participating departments to be queried based on the metadata conversion rules of the logical field names corresponding to the target query request in the pre-generated cross-departmental virtual data table, and sends the corresponding sub-query request to the application server of each business participating department to be queried.
[0153] The cross-department virtual data table can be pre-built by the central server based on the source data tables of all business participating departments. Based on this, before S205, the cross-department data collaborative processing method can also include the following steps: Figure 6 S601 to S605 shown are described in detail as follows:
[0154] S601: The central server obtains the table name of the source data table of each business participating department and the actual field name, data type and business meaning of each field contained in the source data table from the application server of each business participating department.
[0155] The source data table is a physical table used to store real data. In practice, the structure of the source data tables of each participating business department can be the same or different. For example, the source data table of the sponsoring department can be a table based on the structured query language (SQL), the source data table of collaborating department A can be a database based on the structure of Oracle, and the source data table of collaborating department B can be a table based on the structure of MongoDB.
[0156] For example, the application server of the sponsoring department can be configured with a "Main Business Processing Table." This table can include the following fields: business identifier (ID), associated entity ID, processing status, primary responsible person, and completion date. The "Processing Status" field can take values of "Processing," "Completed," and "Archived." The application server of collaborative department A can be configured with a "Related Business Review Table." This table can include the following fields: associated business number, associated entity ID, review status, review responsible person, and review completion date. The "Review Status" field can take values of "Reviewing," "Review Passed," and "Archived." Based on this, the central server can obtain the "Main Business Processing Table" and the actual field names (e.g., business ID, associated entity ID, primary responsible person, and processing result), data types, and business meanings of each field contained in the "Main Business Processing Table" from the application server of the sponsoring department. At the same time, the central server can also obtain the "Related Business Review Table" of the collaborative department A and the actual field names (such as related business number, related entity ID, review person in charge and review status, etc.), data types and business meanings of each field contained in the "Related Business Review Table" from the application server of the collaborative department A.
[0157] S602, the central server clusters all actual field names from each source data table according to business meaning to obtain multiple field name sets; the business meanings corresponding to all actual field names in the same field name set are the same; the business meanings of the fields corresponding to the actual field names in different field name sets are different.
[0158] It is understandable that a field name set may include only one actual field name or multiple actual field names. For ease of explanation, the embodiments of this application will subsequently describe a field name set including multiple actual field names as a first field name set, and a field name set including only one actual field name as a second field name set.
[0159] S603, the central server determines a corresponding logical field name for each first field name set including multiple actual field names, and establishes a mapping relationship between each logical field name and all actual field names in the corresponding first field name set.
[0160] For example, the central server may determine the logical field name corresponding to the set of two actual field names, "business ID" and "associated business number," as "unified business identifier," and establish a mapping relationship between the "unified business identifier" and the "business ID" in the main business processing table and the "associated business number" in the associated business review table. The central server may also determine the logical field name corresponding to the set of two actual field names, "primary entity ID" and "associated entity ID," as "unified entity identifier," and establish a mapping relationship between the "unified entity identifier" and the "primary entity ID" in the main business processing table and the "associated entity ID" in the associated business review table. The central server may also determine the logical field name corresponding to the set of two actual field names, "primary person in charge" and "audit person in charge," as "unified handler," and establish a mapping relationship between the "unified handler" and the "primary person in charge" in the main business processing table and the "audit person in charge" in the associated business review table. The central server can also determine the logical field name corresponding to the set of two actual field names including "processing status" and "audit status" as "unified business status", and establish a mapping relationship between "unified business status" and the "processing status" in the main business processing table and the "audit status" in the associated business audit table.
[0161] S604: The central server determines the actual field names in each second field name set that contains only one actual field name as logical field names corresponding to each second field name set.
[0162] For example, the central server may determine the logical field name corresponding to the second field name set including only one actual field name, namely, "Final Processing Conclusion," as "Final Processing Conclusion." The central server may also determine the logical field name corresponding to the second field name set including only one actual field name, namely, "Subsequent Processing Status," as "Subsequent Processing Status."
[0163] S605: The central server creates a cross-departmental virtual data table containing all logical field names, configures a common data type for each logical field name, and configures metadata conversion rules for the target logical field name.
[0164] The target logical field name can be a logical field name that has a mapping relationship with multiple actual field names in the cross-departmental virtual data table. For example, in the example of S603 above, "Case Unique Identifier," "Party Identifier," and "Handling Personnel" are all target logical field names.
[0165] It is understandable that since the field names and business meanings of the corresponding fields in the source data tables of different departments are usually different for each target logical field name in the cross-departmental virtual data table, it is necessary to configure corresponding metadata conversion rules for each target logical field name in the cross-departmental virtual data table.
[0166] The metadata conversion rules may be used to describe the sources of various actual field names that have a mapping relationship with the target logical field name and the value conversion logic between different actual field names.
[0167] Exemplarily, the metadata conversion rules for the target logical field name "unified business status" in the cross-departmental virtual data table can be configured as: mapping with the actual field name "processing status" in the "main business processing table" from the sponsoring department and the actual field name "audit status" in the "associated business audit table" from the collaborative department A, and when the value of "processing status" in the "main business processing table" of the sponsoring department is "in process", the value of "audit status" in the "associated business audit table" of the collaborative department A is "in audit".
[0168] Based on this, let's assume the target query request is to query for "unified business IDs" whose "unified business status" is "completed." Since the metadata conversion rule for the logical field name "unified business status" in the cross-departmental virtual data table is to map it to the actual field name "processing status" from the sponsoring department's "main business processing table" and the actual field name "audit status" from the "associated business audit table" of collaborating department A, and if the actual field name "processing status" in the "main business processing table" is "completed," the actual field name "audit status" in the "associated business audit table" is "approved," the central server can identify the sponsoring department and collaborating department A as the participating departments in the business to be queried. The sub-query request generated by the central server for the sponsoring department can be: query for "business IDs" whose "processing status" is "completed," and the sub-query request generated by the central server for collaborating department A can be: query for "associated business numbers" whose "audit status" is "approved."
[0169] As can be seen, the cross-departmental virtual data table is composed of common and differentiated fields from the source data tables of all participating business departments. It should be noted that the cross-departmental virtual data table is not a physical data table used to store real data. It is a logically unified and physically decentralized data view generated based on the source data tables of each participating business department. It is equivalent to a cross-departmental data query dictionary, which can provide a reference for cross-departmental data queries. This not only maintains the data consistency of each participating business department, but also breaks down the data barriers between departments without physical data migration, thereby improving data query efficiency.
[0170] Optionally, in order to improve data security, in S205, corresponding sub-query requests are sent to the application servers of the business participating departments to be queried, which may specifically include the following steps 4.1:
[0171] In step 4.1, the central server determines the target transmission channel based on the sensitive attributes of the sub-query result requested by the sub-query request and the target scenario targeted by the cross-departmental collaborative request, and sends the corresponding sub-query request carrying the target transmission channel to the application server of each business participating department to be queried, so that the application server of each business participating department to be queried returns the corresponding sub-query result to the central server through the corresponding target transmission channel.
[0172] The sensitive attribute of the sub-query result requested by the sub-query request may be used to indicate whether the sub-query result requested by the sub-query request contains sensitive data.
[0173] For example, the sensitive attribute may include sensitive or non-sensitive.
[0174] Optionally, when the sub-query result requested by the sub-query request contains sensitive data, the central server may determine that the sensitive attribute of the sub-query result requested by the sub-query request is sensitive; optionally, when the sub-query result requested by the sub-query request does not contain sensitive data, the central server may determine that the sensitive attribute of the sub-query result requested by the sub-query request is non-sensitive.
[0175] Target scenarios can include real-time query scenarios or batch analysis scenarios.
[0176] Optionally, if the cross-departmental collaboration request is a request initiated by the user in the real-time query service section, the central server may determine the target scenario for the cross-departmental collaboration request as the real-time query scenario. Optionally, if the cross-departmental collaboration request is a request initiated by the user in the batch analysis service section, the central server may determine the target scenario for the cross-departmental collaboration request as the batch analysis scenario.
[0177] Based on this, step 4.1 can include steps 4.11 to 4.14, which are detailed as follows:
[0178] In step 4.11, when the sensitive attribute is sensitive and the target scenario is a real-time query scenario, the central server determines the dedicated encrypted channel between the application server of the business participating department to be queried and the central server as the target transmission channel, and obtains the health attributes of the dedicated encryption channel in real time. When the dedicated encryption channel is determined to be in an abnormal state based on the health attributes, the backup encryption channel between the application server of the business participating department to be queried and the central server is determined as the target transmission channel.
[0179] It is understood that since real-time query scenarios require high real-time data performance, the central server can monitor the health attributes of the dedicated encrypted channel in real time after determining it as the target transmission channel. For example, the health attributes include packet loss rate and latency rate.
[0180] The packet loss rate can be used to indicate the data transmission reliability and integrity of the dedicated encrypted channel, and the delay rate can be used to indicate the data transmission speed of the dedicated encrypted channel.
[0181] Optionally, if the packet loss rate of the dedicated encrypted channel within a preset time period is less than or equal to a preset packet loss rate threshold, and the delay rate is less than or equal to a preset delay rate, the central server may determine that the health attribute of the dedicated encrypted channel is healthy (indicating that the dedicated encrypted channel is in a normal state). Optionally, if the packet loss rate of the dedicated encrypted channel within a preset time period is greater than a preset packet loss rate threshold, or the delay rate is greater than a preset delay rate, the central server may determine that the health attribute of the dedicated encrypted channel is unhealthy (indicating that the dedicated encrypted channel is in an abnormal state). The length of the preset time period can be set according to actual needs.
[0182] The embodiment of the present application not only improves the security of data transmission but also improves the stability of data transmission by setting up a backup encryption channel for the dedicated encryption channel, thereby improving the reliability and efficiency of real-time query of sensitive data.
[0183] In step 4.12, when the sensitive attribute is sensitive and the target scenario is a batch analysis scenario, the central server determines the dedicated encrypted channel and the target encrypted channel between the application server of the business participating department to be queried and the preset sandbox as the target transmission channel.
[0184] The pre-configured sandbox can be deployed on a separate server from the central server. For example, the pre-configured sandbox could be deployed on a data server within the political and legal department that manages the various business units involved. It should be noted that the pre-configured sandbox is an independent operating environment isolated from the main system.
[0185] It is understandable that since the batch analysis scenario does not have high requirements for the real-time performance of data, when the real-time query scenario and the batch analysis scenario are sent at the same time and both require the use of dedicated encryption channels or backup encryption channels, the central server can prioritize the dedicated encryption channels and backup encryption channels to the real-time query scenario to improve the data query efficiency in the real-time query scenario.
[0186] In this embodiment, the central server identifies the dedicated encryption channel and the target encryption channel as the target transmission channel, and sends a subquery request carrying the target transmission channel to the application server of the business participant department to be queried. The business participant department to be queried can then call the data query service to execute the subquery request and obtain the original results corresponding to the subquery request. The business participant department to be queried can then send the original results with the digital watermark added to them to a preset sandbox via the target encryption channel. The preset sandbox can then perform batch analysis on the received original results to obtain the subquery results and return the subquery results to the business participant department to be queried via the target encryption channel. The business participant department to be queried can then return the subquery results to the central server via the dedicated encryption channel or the backup encryption channel.
[0187] In step 4.13, when the sensitive attribute is non-sensitive and the target scenario is a real-time query scenario, the central server determines the first public transmission channel between the application server of the business participating department to be queried and the central server as the target transmission channel.
[0188] For example, the first public transmission channel may be a network transmission channel. For example, if the business participating departments to be queried include collaborative department A, the first public transmission channel may be a public information service platform designated by collaborative department A. If the business participating departments to be queried include the sponsoring department, the first public transmission channel may be the sponsoring department's public information portal website.
[0189] In step 4.14, when the sensitive attribute is non-sensitive and the target scenario is a batch analysis scenario, the central server determines the first public transmission channel and the second public transmission channel between the application server of the business participating department to be queried and the preset sandbox as the target transmission channel.
[0190] Exemplarily, the second public transmission channel may also be a network transmission channel.
[0191] In this embodiment, the central server identifies the first and second public transmission channels as target transmission channels and sends a subquery request carrying the target transmission channels to the application server of the business participant department to be queried. The business participant department to be queried can then call the data query service to execute the subquery request and obtain the original results corresponding to the subquery request. The business participant department to be queried can send the original results with a digital watermark to a preset sandbox via the second public transmission channel. The preset sandbox can perform batch analysis on the received original results to obtain subquery results and return the subquery results to the business participant department to be queried via the second public transmission channel. The business participant department to be queried can return the subquery results to the central server via the first public transmission channel or the backup encrypted channel.
[0192] S206: The central server integrates the sub-query results returned by the application servers of the business participating departments to be queried, obtains the target query result corresponding to the target query request, and returns the target query result to the application server that initiated the cross-department collaboration request.
[0193] After receiving each subquery result, the central server can unify the data format of the corresponding actual field names in each subquery result based on the data format of the target logical field name in the virtual data table. Furthermore, based on the metadata conversion rules for the target logical field name in the virtual data table, the central server can convert the actual field names contained in each subquery result into corresponding logical field names. The central server can then integrate all subquery results after data format unification and field name conversion to obtain the target query result.
[0194] Optionally, each time the application server of each business participating department receives the target query result corresponding to the target query request, if the target query result does not include sensitive data, the application server can cache the target query result corresponding to the target query request in the local cache, and can upload the target query result corresponding to the target query request to the distributed cache.
[0195] It is understandable that the application server of each business participating department only caches the target query results corresponding to the target query request initiated by itself. The distributed cache can cache the target query results corresponding to the target query requests initiated by the application servers of all business participating departments.
[0196] Optionally, to reduce the pressure on the local cache and distributed cache, the local cache of each business department's application server can cache the target query results corresponding to each different target query request that was frequently accessed during the department's first target time period (e.g., the current day). The distributed cache can cache the target query results corresponding to each different target query request that was frequently accessed during the department's second target time period (e.g., the past week).
[0197] From the above, it can be seen that the embodiment of the present application can provide a logically unified and physically dispersed data view for all business participating departments by constructing a cross-departmental virtual data table based on the source data table of each business participating department. In this way, the data barriers between departments can be broken without migrating the physical data table, thereby improving the query efficiency of cross-departmental data. In addition, by configuring a secondary preset cache system, when there is a target query result corresponding to the target query request in the preset cache system, the target query result is obtained from the preset cache system first, thereby further shortening the overall response time of cross-departmental collaborative requests and further improving the query efficiency of cross-departmental data.
[0198] See also Figure 7 , is a schematic flow chart of a method for collaborative processing of cross-departmental data provided by another embodiment of the present application. Figure 7 As shown, in some other embodiments of the present application, the method for collaboratively processing cross-departmental data may further include S701 to S704, which are described in detail as follows:
[0199] S701, when the target atomic service includes a data update service, the application server of the business participating department where the data update service is located receives a data update request from the central server, executes the data update request, and records an execution log of the data update request.
[0200] Optionally, after receiving the data update request, the application server of the business participating department where the data update service is located may call the data update service to execute the data update request.
[0201] It is understood that after the application server of the business participating department where the data update service is located calls the data update service to execute a data update request, the data update request may be successfully executed or failed. If the data update request is successfully executed, it means that the data to be updated targeted by the data update request can be updated; if the data update request is executed, it means that the data to be updated targeted by the data update request cannot be updated.
[0202] It should be noted that after the application server calls the data update service to execute the data update request and before submitting the update information, the data to be updated targeted by the data update request is only temporarily updated but not actually updated; only after the update information is submitted will the data to be updated be actually updated.
[0203] S702, when the data update request is successfully executed, the application server of the business participating department where the data update service is located returns a first message to the central server to indicate that it is ready; when the data update request fails to be executed, the application server of the business participating department where the data update service is located returns a second message to the central server to indicate that the preparation has failed.
[0204] S703, when all application servers of the business participating departments where the data update service is located return the first message, the central server sends an update submission request to the application servers of all business participating departments where the data update service is located, so that the application servers of all business participating departments where the data update service is located save the execution results corresponding to the data update request.
[0205] S704, when the application server of at least one business participating department where the data update service is located returns the second message, the central server sends a rollback request to the application servers of all business participating departments where the data update service is located, so that the application servers of all business participating departments where the data update service is located cancel the execution results corresponding to the data update request according to the execution log.
[0206] In actual applications, after executing a data update request, the application server of each business department participating in the data update service will also record the execution log of this data update request. This execution log can record the value of the data to be updated before the update. Based on this, when the application server of the business department participating in the data update service receives a rollback request, it can roll back the value of the data to be updated to the value before the update based on the execution log, thereby undoing the execution result of the corresponding data update request.
[0207] The embodiment of the present application configures the data update method of the data update service as a two-stage verification update method, so that only when the data to be updated in the application servers of the business participating departments where all data update services are located can be updated, the application servers of the business participating departments where each data update service is located are controlled to actually update the data to be updated, thereby ensuring the consistency of data in the entire system.
[0208] In some other embodiments of the present application, the method for collaboratively processing cross-departmental data may further include steps 5.1 and 5.2, which are described in detail as follows:
[0209] Step 5.1, for any target atomic service included in the target service scheduling strategy, the central server counts the first number of timeout errors, the second number of exception errors, and the third number of business errors generated by the target atomic service within the preset time period, and counts the fourth number of total requests received by the target atomic service within the preset time period, and determines the ratio of the sum of the first number, the second number, and the third number to the fourth number as the call error rate of the target atomic service.
[0210] Optionally, in order to ensure that the execution of the cross-departmental collaborative request is not interrupted due to the abnormality of an individual target atomic service and to shorten the overall response time of the cross-departmental collaborative request, the central server may count the first number of timeout errors, the second number of abnormal errors, and the third number of business errors generated by each target atomic service within a preset time period during the execution of the cross-departmental collaborative request, and count the fourth number of total requests received by each target atomic service within the preset time period.
[0211] The timeout error may refer to an error caused by the target atomic service failing to respond to the received service request within its maximum response time.
[0212] An abnormal error may refer to an error in which the target atomic service encounters an unexpected system failure when executing a service request, causing the program to crash and fail to technically execute the service request.
[0213] A service error may refer to an error caused by the target atomic service itself running normally but the service request it receives does not comply with the service scope of the target atomic service.
[0214] The preset time period may be set according to actual needs. For example, the preset time period may be the first time period (eg, 5 minutes) before the central server receives the cross-department coordination request.
[0215] In step 5.2, when the call error rate of the target atomic service is greater than the preset error rate threshold, the central server does not send the corresponding service request to the target atomic service, and returns the corresponding service request to the application server that initiates the cross-departmental collaborative request, so that the application server that initiates the cross-departmental collaborative request obtains the service result corresponding to the corresponding service request from the preset cache system.
[0216] For example, the preset error rate can be set according to actual needs.
[0217] The embodiment of the present application adopts a degraded service strategy of obtaining the corresponding service result from the preset cache system when any target atomic service in the target service scheduling strategy generates an exception, thereby ensuring that the execution of cross-departmental collaborative requests will not be interrupted due to the exception of individual target atomic services, and can shorten the overall response time of cross-departmental collaborative requests.
[0218] It can be understood that the size of the serial numbers of the steps in the above embodiments does not mean the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of this application.
[0219] In the above embodiments, the description of each embodiment has its own focus. For parts that are not described or recorded in detail in a certain embodiment, reference can be made to the relevant description of other embodiments.
[0220] It should be noted that, unless otherwise specified, all technical terms used in the embodiments of this application have the same meanings as those commonly understood by those skilled in the art in the technical field of this application. The technical terms used in the embodiments of this application are only used to explain the specific embodiments of this application and are not intended to limit this application.
[0221] The phrase "embodiment" mentioned in the description of the embodiments of the present application means that the specific features, structures, or characteristics described in conjunction with the embodiment may be included in at least one embodiment of the present application. The appearance of this phrase in various places in the specification does not necessarily refer to the same embodiment, nor does it refer to independent or alternative embodiments that are mutually exclusive with other embodiments. It is understood explicitly and implicitly by those skilled in the art that the embodiments described herein may be combined with other embodiments.
[0222] Those skilled in the art will appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, or a combination of computer software and electronic hardware. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professional and technical personnel can use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.
[0223] The above-described embodiments are only used to illustrate the technical solutions of the present application, rather than to limit them. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or make equivalent replacements for some of the technical features therein. These modifications or replacements do not deviate the essence of the corresponding technical solutions from the spirit and scope of the technical solutions of the various embodiments of the present application, and should all be included in the scope of protection of the present application.
Claims
1. A collaborative processing method for cross-departmental data, characterized in that: include: The central server constructs a feature space dictionary of service capability vectors; The feature space dictionary includes n Functional label feature items, m Quality indicator feature items and s Constraint condition feature items; The dimension of the feature space dictionary is X , X = n + m + s ; For each atomic service, the central server calculates a score value of the atomic service relative to each feature item in the feature space dictionary, and determines a vector composed of the score values of the atomic service relative to all the feature items as a service capability vector of the atomic service; When an application server of any business participating department receives a cross-department collaboration request from a user terminal of the department, it sends the cross-department collaboration request to the central server; The central server determines a request vector of the cross-departmental collaborative request, and calculates a similarity between the request vector and a service capability vector of each of the atomic services; The dimension of the request vector is the same as the dimension of the service capability vector; The central server determines the atomic service having a similarity with the request vector greater than or equal to a first similarity threshold as a candidate atomic service; The central server randomly combines a plurality of different original service scheduling strategies from the candidate atomic services, calculates the total response time and total resource consumption score of each of the original service scheduling strategies, and determines the original service scheduling strategy whose total response time is less than a preset duration and whose total resource consumption score is less than a preset score as the target service scheduling strategy; The target service scheduling strategy is used to describe the optimal service combination and optimal service calling sequence for executing the cross-departmental collaborative request; The central server sends corresponding service requests to the application servers of the business participating departments where the target atomic services in the optimal service combination are located in sequence according to the optimal service calling order; In the case where the target atomic service includes a data query service, the application server of the business participating department where the data query service is located queries, based on the target query request from the central server, whether there is a target query result corresponding to the target query request in the preset cache system; In the case that the target query result does not exist in the preset cache system, the application server of the business participating department where the data query service is located sends the target query request to the central server, so that the central server determines the sub-query request for the source data table of one or more business participating departments to be queried according to the metadata conversion rule of the target logical field name corresponding to the target query request in the pre-generated cross-department virtual data table, and sends the corresponding sub-query request to the application server of each business participating department to be queried; the cross-department virtual data table is constructed by the central server based on the source data tables of all the business participating departments; The central server integrates the sub-query results returned by the application servers of the business participating departments to be queried, obtains the target query result corresponding to the target query request, and returns the target query result to the application server that initiated the cross-department collaboration request.
2. The method according to claim 1, characterized in that For each of the atomic services, the central server calculates a score value of the atomic service relative to each feature item in the feature space dictionary, including: For each of the atomic services, the central server calculates the term frequency-inverse document frequency of each of the function label feature items in the feature space dictionary relative to the atomic service, and determines the normalized term frequency-inverse document frequency corresponding to each of the function label feature items as the score value of the atomic service relative to each of the function label feature items; For each of the atomic services, the central server normalizes the actual value of each of the quality indicator feature items of the atomic service in the feature space dictionary to obtain a score value of the atomic service relative to each of the quality indicator feature items; For each of the atomic services, when the atomic service needs to be constrained by the constraint-type feature item in the feature space dictionary, the central server determines that the score value of the atomic service relative to the constraint-type feature item is 1; when the atomic service does not need to be constrained by the constraint-type feature item in the feature space dictionary, the central server determines that the score value of the atomic service relative to the constraint-type feature item is 0.
3. The method according to claim 2, characterized in that For each of the atomic services, the central server calculates the term frequency-inverse document frequency of each of the function tag feature items in the feature space dictionary relative to the atomic service, including: The central server calculates the word frequency of the keywords corresponding to each of the function tag feature items in the function description document of each of the atomic services using a first formula; the first formula is: ; in, TF i,j For the i The keywords corresponding to the functional label feature items are in the j The frequency of words in the functional description document of the atomic service, N i,j For the i The keywords corresponding to the functional label feature items are in the j The number of times the atomic service appears in the functional description document, N all The keywords corresponding to all the functional label feature items are in the j The total number of times the atomic service appears in the functional description document, 1≤ i ≤ n , 1≤ j ≤| D |, i and j is an integer, | D |The total number of services for the atom; The central server calculates the inverse document frequency of the keyword corresponding to each of the function tag features relative to the function description documents of all the atomic services using a second formula; the second formula is: ; in, IDF i For the i The inverse document frequency of the keywords corresponding to the function label feature items relative to the function description documents of all the atomic services, log() is a logarithmic operation, |{ j : t i ∈ d j }|To include the i the number of function description documents containing the keywords corresponding to the function tag feature items; For each of the function tag feature items, the central server determines the product of the word frequency of the keyword corresponding to the function tag feature item and the inverse document frequency as the word frequency-inverse document frequency of the function tag feature item relative to the atomic service.
4. The method according to claim 1, wherein Sending the corresponding sub-query request to the application server of each business participating department to be queried includes: The central server determines the target transmission channel based on the sensitive attributes of the sub-query result requested by the sub-query request and the target scenario targeted by the cross-departmental collaboration request, and sends a corresponding sub-query request carrying the target transmission channel to the application server of each business participating department to be queried, so that the application server of each business participating department to be queried returns the corresponding sub-query result to the central server through the corresponding target transmission channel; the target scenario includes a real-time query scenario or a batch analysis scenario.
5. The method according to claim 4, characterized in that The sensitive attribute includes sensitive or non-sensitive; correspondingly, the central server determines the target transmission channel according to the sensitive attribute of the target logical field name and the target scenario targeted by the cross-departmental collaboration request, including: In the case where the sensitive attribute is sensitive and the target scenario is a real-time query scenario, the central server determines the dedicated encrypted channel between the application server of the business participating department to be queried and the central server as the target transmission channel, obtains the health attribute of the dedicated encrypted channel in real time, and when it is determined that the dedicated encrypted channel is in an abnormal state according to the health attribute, determines the backup encrypted channel between the application server of the business participating department to be queried and the central server as the target transmission channel; In the case where the sensitive attribute is sensitive and the target scenario is a batch analysis scenario, the central server uses the dedicated encrypted channel and the target encrypted channel between the application server of the business participating department to be queried and the preset sandbox as the target transmission channel; When the sensitive attribute is non-sensitive and the target scenario is a real-time query scenario, the central server determines the first public transmission channel between the application server of the business participating department to be queried and the central server as the target transmission channel; When the sensitive attribute is non-sensitive and the target scenario is a batch analysis scenario, the central server determines the first public transmission channel and the second public transmission channel between the application server of the business participating department to be queried and the preset sandbox as the target transmission channel.
6. The method according to any one of claims 1 to 5, characterized in that Also includes: In the case where the target atomic service includes a data update service, the application service of the business participating department where the data update service is located receives the data update request from the central server, executes the data update request, and records an execution log of the data update request; When the data update request is successfully executed, the application server of the business participating department where the data update service is located returns a first message indicating readiness to the central server; In the case where the data update request fails to be executed, the application server of the business participating department where the data update service is located returns a second message indicating the preparation failure to the central server; When all application servers of the business participating departments where the data update service is located return the first message, the central server sends an update submission request to all application servers of the business participating departments where the data update service is located, so that all application servers of the business participating departments where the data update service is located save the execution results corresponding to the data update request; In the case that at least one application server of the business participating department where the data update service is located returns the second message, the central server sends a rollback request to all application servers of the business participating departments where the data update service is located, so that all application servers of the business participating departments where the data update service is located cancel the execution result corresponding to the data update request according to the execution log.
7. The method according to any one of claims 1 to 5, characterized in that Also includes: For any target atomic service included in the target service scheduling strategy, the central server counts a first number of timeout errors, a second number of exception errors, and a third number of business errors generated by the target atomic service within a preset time period, and counts a fourth number of total requests received by the target atomic service within the preset time period, and determines the ratio of the sum of the first number, the second number, and the third number to the fourth number as the call error rate of the target atomic service; When the call error rate of the target atomic service is greater than the preset error rate threshold, the central server does not send the corresponding service request to the target atomic service, and returns the corresponding service request to the application server that initiated the cross-departmental collaboration request, so that the application server that initiated the cross-departmental collaboration request obtains the service result corresponding to the service request from the preset cache system.
8. A cross-departmental data collaborative processing system, characterized by: It includes a central server, an edge node server, and multiple application servers; each of the application servers is deployed in a business participating department; the central server and the edge node server are respectively connected to the multiple application servers, and each application server is connected to one or more user terminals of the department; The central server is used to construct a feature space dictionary of service capability vectors; The feature space dictionary includes n Functional label feature items, m Quality indicator feature items and s Constraint condition feature items; The dimension of the feature space dictionary is X , X = n + m + s ; The central server is further configured to calculate, for each atomic service, a score value of the atomic service relative to each feature item in the feature space dictionary, and determine a vector composed of the score values of the atomic service relative to all the feature items as a service capability vector of the atomic service; The application server is used to send the cross-department collaboration request to the central server when receiving the cross-department collaboration request from the user terminal of the department; The central server is further configured to determine a request vector of the cross-departmental collaborative request and calculate a similarity between the request vector and a service capability vector of each of the atomic services; the dimension of the request vector is the same as the dimension of the service capability vector; The central server is further configured to determine the atomic service having a similarity with the request vector greater than or equal to a first similarity threshold as a candidate atomic service; The central server is further configured to randomly combine a plurality of different original service scheduling strategies from the candidate atomic services, calculate the total response time and total resource consumption score of each of the original service scheduling strategies, and determine the original service scheduling strategy having a total response time less than a preset duration and a total resource consumption score less than a preset score as the target service scheduling strategy; The target service scheduling strategy is used to describe the optimal service combination and optimal service calling sequence for executing the cross-departmental collaborative request; The central server is further configured to send corresponding service requests to the application servers of the business participating departments where the target atomic services in the optimal service combination are located in sequence according to the optimal service calling sequence; In the case where the target atomic service includes a data query service, the application server of the business participating department where the data query service is located is used to query whether there is a target query result corresponding to the target query request in the preset cache system according to the target query request from the central server; The application server of the business participating department where the data query service is located is also used to, when the target query result does not exist in the preset cache system, send the target query request to the central server by the application server of the business participating department where the data query service is located, so that the central server determines the sub-query request for the source data table of one or more business participating departments to be queried according to the metadata conversion rule of the target logical field name corresponding to the target query request in the pre-generated cross-departmental virtual data table, and sends the corresponding sub-query request to the application server of each business participating department to be queried; the cross-departmental virtual data table is constructed by the central server based on the source data tables of all the business participating departments; The central server is also used to integrate the sub-query results returned by the application servers of each of the business participating departments to be queried, obtain the target query result corresponding to the target query request, and return the target query result to the application server that initiated the cross-department collaboration request.
Citation Information
Patent Citations
Cloud-based pension information management system
CN120105478A
Management of data replication and storage apparatuses, methods and systems
US20150347548A1