Cross-component data sharing method, device, equipment and storage medium

Abstract

The present invention relates to a cross-component data sharing method, which aims to solve the problem that business attribute data in the existing low-code development framework cannot be effectively shared and managed among different components. The present invention realizes centralized management and modular storage of business attribute data by constructing a centralized variable pool and integrating the Vuex state machine therein. It includes configuring a business attribute collection plug-in in the business component to push the business attribute data to the centralized variable pool; storing the data in a modular manner, including classification and grouping processing of the data, and dividing it into multiple modules according to business logic, defining the access rights and caching strategies of each module. Finally, the centralized variable pool is accessed through the business component to realize cross-component business attribute data sharing. The present invention effectively reduces the complexity of the system, avoids the redundancy of network requests, and improves the performance and response efficiency of the overall system.

Description

Technical Field

[0001] The present invention relates to the field of computer technology, and in particular to a method, apparatus, device and storage medium for cross-component data sharing. Background Art

[0002] As digital transformation deepens in the modern financial and insurance industries, more and more companies are adopting low-code development platforms (such as Bootstrap) to build their internal and external applications. These low-code platforms simplify application development and accelerate the deployment of business systems by providing visual configuration tools and predefined component libraries. However, as application complexity increases, the limitations of low-code frameworks become increasingly apparent, particularly in data management and data sharing between components.

[0003] In typical low-code development frameworks, metadata is typically managed at the component level. While this approach can meet basic development needs, it presents three major issues when dealing with complex business logic, particularly in the finance and insurance industries:

[0004] Limitations of cross-component data sharing: In traditional low-code frameworks, each component typically manages its business attribute data independently, meaning that business attributes in component A cannot be directly referenced and used by component B. This limitation prevents effective sharing of business attributes between different components, further increasing system complexity. In financial and insurance applications, critical information, such as customer data, policy information, or transaction records, often needs to be shared across multiple components. Therefore, the lack of cross-component data sharing capabilities can limit the system's flexibility and scalability.

[0005] Performance issues caused by event mechanisms: To solve the problem of data sharing between sibling components, low-code frameworks often rely on event mechanisms, which transmit data through event triggering and monitoring. However, this mechanism can easily lead to a large amount of event overhead in large-scale applications, reducing the efficiency of the browser's JavaScript parser. For applications in the financial and insurance industries, processing large amounts of real-time data and complex business logic is a common requirement. If the event mechanism is used improperly, it may cause performance issues and even memory leaks, further affecting system stability and responsiveness.

[0006] Network overhead caused by repeated requests: Because business attributes cannot be referenced repeatedly across components, the system may need to request the same business attribute data from the server multiple times in multiple components. This design leads to redundant network requests, which not only increases network load but also conflicts with the performance optimization principle of reducing the number of HTTP requests. In the financial and insurance industries, frequent network requests can lead to increased system response times, a degraded user experience, and even more severe performance bottlenecks in high-concurrency scenarios.

[0007] In summary, current low-code development frameworks face challenges such as limitations in cross-component data sharing, performance issues caused by event mechanisms, and network overhead caused by repeated requests when handling complex financial and insurance business applications. Therefore, to address these issues, a technical solution is urgently needed that can effectively centrally manage and share business attribute data to improve the overall performance and stability of the system. Summary of the Invention

[0008] The main purpose of the present invention is to provide a cross-component data sharing method, device, equipment and storage medium, aiming to solve the technical problem that business attribute data cannot be effectively shared and managed across components, resulting in increased system complexity, performance degradation and network request redundancy.

[0009] To achieve the above objectives, the present invention provides a cross-component data sharing method, comprising:

[0010] Build a centralized variable pool for centralized management and storage of business attribute data, and integrate the Vuex state machine into the centralized variable pool;

[0011] Configuring a business attribute collection plug-in in the business component, and pushing the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in;

[0012] The business attribute data pushed to the centralized variable pool is stored in the Vuex state machine in a modular manner. The modular storage includes classification and grouping of business attribute data, dividing the data into multiple modules according to different business logics, and defining access rights and caching strategies for each module;

[0013] The centralized variable pool is accessed through business components to achieve sharing of the business attribute data.

[0014] In one embodiment, pushing the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in includes:

[0015] Setting an anti-shake time threshold, when the business attribute collection plug-in receives a data collection instruction, starts the anti-shake mechanism;

[0016] If no new data collection instruction is received within the anti-shake time threshold, the business attribute data is pushed from the business component to the centralized variable pool through the business attribute collection plug-in;

[0017] If a new data collection instruction is received within the anti-shake time threshold, all received data collection instructions are aggregated and merged into one data collection task through the anti-shake mechanism;

[0018] After the anti-shake time threshold ends, the data collection task is executed by the business attribute collection plug-in, and the corresponding business attribute data is collected from the business component and pushed to the centralized variable pool.

[0019] In one embodiment, accessing the centralized variable pool through a business component to achieve sharing of the business attribute data includes:

[0020] Assigning priorities to business attribute data requests based on the importance of the business attribute data;

[0021] In the process of the business component initiating a business attribute data request to the centralized variable pool, the business attribute data request is divided into multiple stages according to the assigned priority, and the business attribute data requests in different stages are processed in order of priority;

[0022] Before the business attribute data request of each stage is sent to the centralized variable pool, a corresponding data request task is generated. The data request task manages and executes the business attribute data request according to priority;

[0023] After the data request task of each stage is generated and sent to the centralized variable pool, the centralized variable pool receives and processes the business attribute data request of each stage and returns the corresponding business attribute data to the business component.

[0024] In one embodiment, the business attribute data pushed to the centralized variable pool is stored in the Vuex state machine in a modular manner, including:

[0025] According to a preset time interval, the business attribute data collected in the centralized variable pool is divided into multiple bands, and business data access requests are sent to the server in sequence;

[0026] After receiving the service attribute data response returned by the server, the service attribute data is parsed and the service attribute data is grouped according to predefined storage rules;

[0027] The grouped data is packaged into independent modules and stored in the Vuex state machine.

[0028] In one embodiment, parsing the business attribute data and grouping the business attribute data according to predefined storage rules includes:

[0029] Parsing the business attribute data, identifying and extracting business fields in the business attribute data;

[0030] According to business requirements and predefined storage rules, each business field is assigned a corresponding rule number, which is used to guide the grouping and storage of business fields;

[0031] Apply the corresponding storage rule according to the rule number of each business field and group the business fields in a modular manner.

[0032] In one embodiment, after grouping the business fields in a modular manner, the method further includes:

[0033] Select rendering target and output format based on business needs or user instructions;

[0034] Extract the grouped and stored business field data from the Vuex state machine, and determine the corresponding rendering template according to the rendering target;

[0035] Binding the extracted business field data to the rendering template, filling the business field data into a specified position of the rendering template, and generating a preliminary rendering result;

[0036] The preliminary rendering result is formatted using the output format to obtain a target rendering result.

[0037] In one embodiment, the business attribute data collected in the centralized variable pool is divided into multiple bands according to a preset time interval, and business data access requests are sent to the server in sequence, including:

[0038] Dividing the business attribute data collected in the centralized variable pool into multiple bands according to preset time intervals;

[0039] Before sending each business data access request, dynamically adjust the frequency of sending the next business data access request based on the current load and network conditions;

[0040] Monitor I / O performance and network conditions in real time, and dynamically adjust the amount of business attribute data sent in each batch;

[0041] Categorize and prioritize business data access requests based on their urgency and importance;

[0042] The service data access request for each band is sent to the server in sequence according to the sending frequency of the service data access request, the quantity and priority of the service attribute data sent in each batch.

[0043] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a cross-component data sharing device, comprising:

[0044] Centralized variable pool module, building a centralized variable pool for centralized management and storage of business attribute data, and integrating the Vuex state machine in the centralized variable pool;

[0045] A business attribute collection plug-in module configures a business attribute collection plug-in in a business component, and pushes the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in;

[0046] The data storage and management module stores the business attribute data pushed to the centralized variable pool in the Vuex state machine in a modular manner. The modular storage includes classification and grouping of business attribute data, dividing the data into multiple modules according to different business logics, and defining the access rights and caching strategies of each module;

[0047] The data access and sharing module accesses the centralized variable pool through the business component to realize the sharing of the business attribute data.

[0048] Furthermore, to achieve the above-mentioned purpose, the present invention also provides a cross-component data sharing device, which includes a memory, a processor, and a cross-component data sharing program stored on the memory and executable on the processor. When the cross-component data sharing program is executed by the processor, the steps of the cross-component data sharing method described above are implemented.

[0049] Furthermore, to achieve the above objectives, the present invention also provides a computer storage medium, on which a cross-component data sharing program is stored, and when the cross-component data sharing program is executed by a processor, the steps of the cross-component data sharing method described above are implemented.

[0050] Beneficial effects: The present invention relates to a cross-component data sharing method, which aims to solve the problem that business attribute data in the existing low-code development framework cannot be effectively shared and managed among different components. The present invention realizes centralized management and modular storage of business attribute data by constructing a centralized variable pool and integrating the Vuex state machine therein. It includes configuring a business attribute collection plug-in in the business component to push the business attribute data to the centralized variable pool; storing the data in a modular manner, including classification and grouping processing of the data, and dividing it into multiple modules according to business logic, and defining the access rights and caching strategies of each module. Finally, cross-component business attribute data sharing is realized by accessing the centralized variable pool through the business component. The present invention effectively reduces the complexity of the system, avoids the redundancy of network requests, and improves the performance and response efficiency of the overall system. BRIEF DESCRIPTION OF THE DRAWINGS

[0051] The present invention will be further described below with reference to the accompanying drawings and embodiments, in which:

[0052] Figure 1 This is a flow chart of an embodiment of a cross-component data sharing method of the present invention;

[0053] Figure 2 A schematic diagram of functional modules of a preferred embodiment of the cross-component data sharing device of the present invention;

[0054] Figure 3 This is a schematic diagram of the structure of the device hardware operating environment involved in the cross-component data sharing device embodiment of the present invention. DETAILED DESCRIPTION

[0055] It should be understood that the specific embodiments described herein are only used to explain the present invention and are not intended to limit the present invention.

[0056] It's worth noting that in the modern financial and insurance industries, as digital transformation deepens, more and more companies are adopting low-code development platforms (such as Bootstrap) to build their internal and external applications. These low-code platforms simplify application development and accelerate the deployment of business systems by providing visual configuration tools and predefined component libraries. However, as application complexity increases, the limitations of low-code frameworks are becoming increasingly apparent, particularly in data management and data sharing between components.

[0057] In typical low-code development frameworks, metadata is typically managed at the component level. While this approach can meet basic development needs, it presents three major issues when dealing with complex business logic, particularly in the finance and insurance industries:

[0058] Limitations of cross-component data sharing: In traditional low-code frameworks, each component typically manages its business attribute data independently, meaning that business attributes in component A cannot be directly referenced and used by component B. This limitation prevents effective sharing of business attributes between different components, further increasing system complexity. In financial and insurance applications, critical information, such as customer data, policy information, or transaction records, often needs to be shared across multiple components. Therefore, the lack of cross-component data sharing capabilities can limit the system's flexibility and scalability.

[0059] Performance issues caused by event mechanisms: To solve the problem of data sharing between sibling components, low-code frameworks often rely on event mechanisms, which transmit data through event triggering and monitoring. However, this mechanism can easily lead to a large amount of event overhead in large-scale applications, reducing the efficiency of the browser's JavaScript parser. For applications in the financial and insurance industries, processing large amounts of real-time data and complex business logic is a common requirement. If the event mechanism is used improperly, it may cause performance issues and even memory leaks, further affecting system stability and responsiveness.

[0060] Network overhead caused by repeated requests: Because business attributes cannot be referenced repeatedly across components, the system may need to request the same business attribute data from the server multiple times in multiple components. This design leads to redundant network requests, which not only increases network load but also conflicts with the performance optimization principle of reducing the number of HTTP requests. In the financial and insurance industries, frequent network requests can lead to increased system response times, a degraded user experience, and even more severe performance bottlenecks in high-concurrency scenarios.

[0061] In summary, current low-code development frameworks face challenges such as limitations in cross-component data sharing, performance issues caused by event mechanisms, and network overhead caused by repeated requests when handling complex financial and insurance business applications. Therefore, to address these issues, a technical solution is urgently needed that can effectively centrally manage and share business attribute data to improve the overall performance and stability of the system.

[0062] See also Figure 1 , Figure 1 This is a flow chart of an embodiment of a cross-component data sharing method provided by the present invention. It should be noted that although a logical order is shown in the flow chart, in some cases, the steps shown or described may be performed in a different order than that shown here.

[0063] like Figure 1 As shown, the cross-component data sharing method proposed by the present invention includes the following steps:

[0064] S10, building a centralized variable pool for centralized management and storage of business attribute data, and integrating the Vuex state machine into the centralized variable pool;

[0065] In this embodiment, the centralized variable pool is a core module for data storage and management, designed to centrally manage business attribute data from multiple business components. Through centralized management, the centralized variable pool eliminates data silos between components and ensures efficient data sharing and access across them. For example, in a financial management system, each business component may involve data such as customer information, transaction records, and credit scores. By centrally storing this business attribute data in the centralized variable pool, the system ensures that different modules (such as customer service, risk control, and credit approval) can share and access the same data source, reducing duplicate requests and optimizing system performance.

[0066] The Vuex state machine is a centralized storage for managing the shared state of all components in an application. Integrating the Vuex state machine within a centralized variable pool ensures that data changes are synchronized across all components that rely on that data, maintaining data consistency. The Vuex state machine also provides features such as time travel debugging, state snapshots, and rollbacks, enhancing the flexibility and reliability of data management. For example, in a financial scenario, imagine a credit approval system that needs to constantly update a customer's credit score. If this data is managed in a centralized variable pool and synchronized to all relevant components via the Vuex state machine, when the credit score changes, the approval system, customer service system, and other related modules will immediately have access to the latest data, ensuring consistent and accurate decision-making.

[0067] In one specific implementation, a centralized variable pool is designed to centrally manage customer credit scores and transaction history data within a financial institution's risk assessment system. The Vuex state machine is not only used for data synchronization but also expanded to include historical version management capabilities, enabling the system to backtrack data versions at different points in time and supporting more refined risk assessments. Furthermore, the business attribute collection plugin has been expanded to include data validation and filtering capabilities to ensure the high quality of data pushed to the centralized variable pool. Regarding data storage, modular storage has added data priority and storage cycle management capabilities, enabling critical data to be prioritized and kept up to date. Finally, when business components access the centralized variable pool, role-based access control is incorporated to ensure data security.

[0068] In another specific embodiment, in an insurance company's claims system, a centralized variable pool is used to centrally store customer policy information and claims application data. The Vuex state machine is extended to support real-time data stream processing, which can automatically update the policy risk score as data flows in. The business attribute collection plug-in increases the processing capabilities of heterogeneous data sources, can integrate structured and unstructured data, and uniformly convert the format for storage. Modular storage adds automated lifecycle management capabilities, allowing inactive data to be automatically migrated to cold storage areas to optimize storage resources. During the data sharing process, the system supports automatically triggering interactions with external systems based on predefined rules, such as automatically sending data requests to reinsurance companies.

[0069] In other specific implementations, within a bank's cross-departmental collaboration system, the centralized variable pool is expanded into a data exchange platform, supporting cross-departmental transactional data operations and ensuring data consistency across all relevant departments. A business attribute collection plug-in adds real-time event response capabilities, instantly collecting and pushing relevant data as events occur. Modular storage uses machine learning to automatically adjust data grouping and storage strategies, improving data access efficiency. When business components access the centralized variable pool, they can also automatically generate data analysis reports to support high-level business decision-making.

[0070] Through the above steps, by building a centralized variable pool and integrating the Vuex state machine, centralized management and real-time synchronization of business attribute data across components are achieved, significantly improving the consistency, security and performance of the system.

[0071] S20: configuring a business attribute collection plug-in in the business component, and pushing the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in;

[0072] In this embodiment, the business attribute collection plug-in is a specially designed module that can be integrated into different business components. Its primary function is to automatically monitor and collect business attribute data within the component, such as customer information and transaction data. This plug-in can be configured to adapt to different business needs, ensuring effective operation in various scenarios. For example, in a financial services application, the collection plug-in can be configured to monitor the loan application form filled out by the user. When the user completes the form, the plug-in automatically collects customer information, loan amount, term, and other data from the form and prepares to push it to the centralized variable pool.

[0073] Once the business attribute collection plug-in collects data from a business component, it preprocesses the data (such as data format conversion and validation) and then pushes it to the centralized variable pool. This push process can be synchronous or asynchronous, depending on the system design requirements. This centralized push ensures that data from all components is uniformly stored and shared across other components within the system.

[0074] In one specific implementation, within a loan approval system, a business attribute collection plug-in not only pushes loan application data to a centralized variable pool but is also extended to support data preprocessing and automated scoring. Before pushing the data, the plug-in performs a preliminary score on the applicant's credit information, income data, and loan amount based on predefined rules. The score results, as part of the business attribute data, are pushed to the centralized variable pool along with other application information. This extension enables the system to perform preliminary analysis before the data enters centralized storage, accelerating the subsequent loan approval process. Furthermore, the plug-in adds a data compression function. When the data volume is large, the plug-in compresses the data to reduce the burden on network transmission and ensure that the data can be pushed quickly and securely to the centralized variable pool.

[0075] In another specific implementation, within an insurance claims processing system, the business attribute collection plug-in's functionality has been expanded to support asynchronous data collection and batch push. In this scenario, a customer's claim application may contain multiple files and complex data entries. The plug-in first collects this data asynchronously, processing each submitted item individually and performing data validation and cleanup in the background. Once complete, the plug-in pushes all data entries in batches to a centralized variable pool and automatically generates a summary record for use by the claims review team. This extension reduces system latency during data collection, improves the user experience, and ensures the integrity and consistency of data upon push.

[0076] By configuring business attribute collection plug-ins, the automatic collection and centralized push of data within business components can be achieved, effectively improving the real-time and accuracy of data, ensuring data consistency and system response speed across components, and enhancing the flexibility and scalability of the overall system.

[0077] S30, storing the business attribute data pushed to the centralized variable pool in the Vuex state machine in a modular manner, wherein the modular storage includes classification and grouping of business attribute data, dividing the data into multiple modules according to different business logics, and defining access rights and caching strategies for each module;

[0078] In this embodiment, modular storage refers to classifying and grouping business attribute data according to certain logical standards to make the storage of data in the Vuex state machine more structured and efficient. Through modularization, the system can package related data into independent modules for easy subsequent management and access.

[0079] Classification and grouping are fundamental steps in modular storage. By classifying business attribute data, the system can group data into independent modules based on different business logic. For example, classification and grouping can be performed based on dimensions such as data type, business process, and user role.

[0080] Based on modular storage, the system needs to define access permissions and caching policies for each data module. Access permissions determine which users or system components can access specific data modules, while caching policies determine how this data is cached within the system to improve access efficiency and reduce server load. For example, in a banking system, senior management can access data from all modules, while ordinary employees may only have access to the modules required for their work. Frequently used data modules can be cached for a short period of time to reduce database query times, while infrequently used data modules can be cached for a long period of time or not cached at all to reduce system load.

[0081] In one specific implementation, in a financial institution's risk control system, after business attribute data is pushed to a centralized variable pool, it is first classified according to different business dimensions. For example, the system divides all credit risk-related data into one module and market risk-related data into another module. Each module is stored independently in the Vuex state machine, and different access rights are defined based on user roles. For example, risk assessors can access data from all risk modules, while general employees can only access data from specific modules. To improve system responsiveness, frequently accessed risk modules are set to short-term cache, while historical risk data is not cached and is directly retrieved from the database.

[0082] Through modular storage and refined classification processing, efficient management of business attribute data in the Vuex state machine is achieved, which ensures the accessibility and security of system data, improves the system's response speed and resource utilization efficiency, and makes data management more flexible and reliable.

[0083] S40, accessing the centralized variable pool through the business component to achieve sharing of the business attribute data.

[0084] In this embodiment, business components can access data in a centralized variable pool through interfaces or method calls. This means that each business component does not need to store and manage all business data independently. Instead, it can directly obtain the required data from the centralized storage pool. This process typically involves sending a data request, receiving a response, and using the data within the component.

[0085] By allowing business components to access a centralized variable pool, the system enables cross-component data sharing. Each business component can access shared data resources, avoiding data redundancy and inconsistency. Data sharing can be synchronous or asynchronous, depending on the system design and requirements.

[0086] In one specific implementation, within a bank's loan approval system, business components share loan application data and customer credit scores by accessing a centralized variable pool. This system introduces a dynamic data caching mechanism. Specifically, when the loan approval component needs to obtain a customer's credit score, the system first checks whether the data is in the local cache. If valid data exists in the cache, it is used directly; otherwise, the latest data is obtained from the centralized variable pool and the cache is updated. This extension reduces the number of direct accesses to the centralized variable pool and improves system response speed. Furthermore, the system sets different cache expiration dates for different data modules. For example, the cache expiration date for customer credit scores is shorter, while the cache expiration date for historical loan records is longer. This extension ensures real-time data availability and efficient system operation.

[0087] In other specific implementations, in financial trading platforms, business components share trading data and market data by accessing a centralized variable pool, but the system further expands the asynchronous data loading mechanism. To cope with highly concurrent trading requests, the system has designed asynchronous data loading and processing capabilities. After a business component initiates a data request, the system immediately returns a data request task ID, and the component can asynchronously obtain data results based on this ID. This extension allows business components to continue processing other tasks while waiting for data to be returned, improving the system's throughput and response speed. In addition, the system has expanded the data priority processing function. Different types of transaction data are assigned different priorities based on urgency. High-priority data requests are processed first and the results are returned first, ensuring that critical transactions can be executed in a timely manner.

[0088] By accessing the centralized variable pool through business components, cross-component data sharing is achieved, data redundancy and inconsistency are reduced, system coordination and response speed are improved, and each business component is ensured to have access to the latest shared data, thereby improving the overall efficiency and business processing capabilities of the system.

[0089] The present invention relates to a cross-component data sharing method, which aims to solve the problem that business attribute data in the existing low-code development framework cannot be effectively shared and managed among different components. The present invention realizes centralized management and modular storage of business attribute data by constructing a centralized variable pool and integrating the Vuex state machine therein. It includes configuring a business attribute collection plug-in in the business component to push the business attribute data to the centralized variable pool; storing the data in a modular manner, including classification and grouping processing of the data, and dividing it into multiple modules according to business logic, defining the access rights and caching strategies of each module. Finally, the centralized variable pool is accessed through the business component to realize cross-component business attribute data sharing. The present invention effectively reduces the complexity of the system, avoids the redundancy of network requests, and improves the performance and response efficiency of the overall system.

[0090] In one embodiment, in the above S20, pushing the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in includes:

[0091] S201, setting an anti-shake time threshold, when the service attribute collection plug-in receives a data collection instruction, starting an anti-shake mechanism;

[0092] S202: If no new data collection instruction is received within the anti-shake time threshold, push the business attribute data from the business component to the centralized variable pool through the business attribute collection plug-in;

[0093] S203, if a new data collection instruction is received within the anti-shake time threshold, aggregating all received data collection instructions through the anti-shake mechanism and merging them into one data collection task;

[0094] S204: After the anti-shake time threshold ends, the data collection task is executed by the business attribute collection plug-in to collect corresponding business attribute data from the business component and push it to the centralized variable pool.

[0095] In this embodiment, the anti-shake time threshold is used to determine whether a data collection instruction needs to be executed immediately within a certain time period. The anti-shake mechanism uses the set time threshold to avoid triggering data push every time between frequent data collection instructions. This mechanism is activated based on the first data collection instruction received.

[0096] When new data collection instructions are received within the debounce time threshold, the debounce mechanism aggregates these instructions into a single data collection task. This means that the system only executes a single data push operation within a certain period of time, including all collected data. This process optimizes system resource utilization and reduces the overhead of repeated data transmission.

[0097] After the debounce time threshold expires, the system executes the aggregated data collection task through the business attribute collection plug-in. At this point, the system collects all corresponding business attribute data from the business components and pushes it to the centralized variable pool. This mechanism ensures the timeliness and accuracy of data push while reducing the impact of frequent push operations on the system.

[0098] In one specific implementation, within a financial transaction system, the debounce mechanism is expanded to include a dynamic adjustment mechanism based on transaction type. The system dynamically sets debounce time thresholds based on the urgency and importance of user transactions. For example, for high-frequency, small-value transactions, the system sets a shorter debounce time threshold to ensure that transaction data can be quickly pushed to a centralized variable pool for immediate analysis by subsequent risk control components. For large or complex transactions, the system sets a longer debounce time threshold to aggregate more transaction data for batch processing. This expansion allows the system to flexibly adjust data collection and push strategies based on different transaction types, optimizing system performance and security.

[0099] In another specific embodiment, within an insurance company's claims processing system, the de-shake mechanism is expanded to an intelligent de-shake mechanism based on user behavior analysis. Based on historical data and user behavior patterns, the system predicts whether a user is likely to submit multiple claims in a short period of time. If the system detects that a user is likely to submit multiple claims within a short period of time, the de-shake time threshold is automatically extended to aggregate more instructions for combined processing. Conversely, if the user's behavior appears to be a one-time operation, the de-shake time threshold is shortened, and data push is executed immediately. This behavior-based extension improves the system's adaptability to user operations, ensuring an optimal balance between user experience and system efficiency.

[0100] By introducing an anti-shake mechanism, this embodiment can effectively reduce unnecessary frequent push operations during the collection of business attribute data. It optimizes data transmission by aggregating multiple instructions, improves the system's response speed and resource utilization efficiency, and ensures the accuracy and timeliness of data push, thereby improving the overall system stability and user experience.

[0101] In one embodiment, the above S40 includes:

[0102] S401, assigning a priority to a business attribute data request according to the importance of the business attribute data;

[0103] S402, in the process of the business component initiating a business attribute data request to the centralized variable pool, dividing the business attribute data request into multiple stages according to the assigned priorities, and processing the business attribute data requests in different stages in order of priority;

[0104] S403, before the business attribute data request of each stage is sent to the centralized variable pool, a corresponding data request task is generated, and the data request task manages and executes the business attribute data request according to priority;

[0105] S404, after the data request task of each stage is generated and sent to the centralized variable pool, the centralized variable pool receives and processes the business attribute data request of each stage, and returns the corresponding business attribute data to the business component.

[0106] In this embodiment, the system assigns different priorities to each data request based on the importance of the business attribute data. This process typically occurs before a business component initiates a data request, ensuring that more important data is processed and responded to first. For example, in a banking system, a customer's account balance inquiry request might be assigned a high priority, while a non-urgent request for historical transaction records might be assigned a low priority. This allows the system to process high-priority requests first, ensuring a faster response time for critical business operations.

[0107] The priority allocation rules can be: highest priority: used for urgent and critical business requests, such as large-scale fund transfers and emergency system alarms, which are processed immediately and take precedence over all other requests; high priority: used for important but non-urgent business requests, such as core data processing and important customer inquiries, which are processed as soon as possible and take precedence over medium and low priorities; medium priority: used for routine business requests, such as ordinary account inquiries and daily data processing, which are processed after high-priority tasks; low priority: used for low-impact business requests, such as historical data queries and log backups, which are processed when system resources are idle; lowest priority: used for non-critical background tasks, such as data archiving and system maintenance, which are executed after all other requests are processed.

[0108] When a business component initiates a data request, the system divides the request into multiple stages based on the assigned priority. The system processes data requests at each stage in order of priority, ensuring that high-priority requests receive priority responses.

[0109] Before sending data requests at each stage, the system generates a corresponding data request task. This task is responsible for managing and executing data requests according to priority, and ensuring that data requests are processed in the expected priority order.

[0110] After the data request tasks are generated and sent at each stage, the centralized variable pool is responsible for receiving and processing these requests. The system processes the data in sequence according to the priority of the request and returns the corresponding business attribute data to the business component to meet business needs.

[0111] In one specific embodiment, in a bank's multi-account management system, the system assigns different priorities to data requests based on account type and transaction type. For example, requests involving large-value fund transfers are assigned the highest priority, while inquiries about small-value consumption records are assigned a lower priority. When processing these requests, the system first divides the requests into multiple stages based on priority, and high-priority requests are processed and responded to immediately. The extended technical feature is that when high-priority requests are processed, the system monitors changes in account status in real time and dynamically adjusts the processing order of low-priority requests. For example, if an account anomaly is detected during the processing of a high-priority request, the system will prioritize terminating low-priority requests and re-evaluate their processing priority. In this way, the system ensures the security and accuracy of critical operations.

[0112] In another specific embodiment, in the risk assessment system of an insurance company, the system assigns priorities to data requests based on the risk level of the customer. Data requests from high-risk customers (such as credit scores, historical default records) are assigned high priority, while data requests from low-risk customers are assigned low priority. The technical feature of the extension is that the system introduces a parallel processing mechanism in the data request stage. When high-priority data requests are processed in stages, the system will process the associated medium and low priority requests in parallel to reduce the overall response time. For example, when processing a credit score query for a high-risk customer, the system will also process requests for their historical default records in parallel. This extension enables the system to improve the overall data processing efficiency while ensuring rapid response to high-priority requests.

[0113] Through priority management and phased processing of data requests, this embodiment can effectively ensure priority response to key data when the system processes multiple business requests, thereby improving the system's processing efficiency and response speed, while ensuring consistency and stability in the data sharing process.

[0114] In one embodiment, in the above S30, the business attribute data pushed to the centralized variable pool is stored in the Vuex state machine in a modular manner, including:

[0115] S301, dividing the business attribute data collected in the centralized variable pool into multiple bands according to a preset time interval, and sending business data access requests to the server in sequence;

[0116] S302, after receiving the service attribute data response returned by the server, parsing the service attribute data and grouping the service attribute data according to predefined storage rules;

[0117] S303, packaging the grouped data into independent modules and storing them in the Vuex state machine.

[0118] In this embodiment, the system divides business attribute data collected from a centralized variable pool into multiple bands at preset time intervals. These data bands are organized according to a specific logic and sequence, with the data in each band representing a data set. The system then sequentially sends data access requests to the server to retrieve and process this data. For example, in a financial system, the system might collect customer transaction data every five minutes, divide it into multiple bands, and send data requests to the server in sequence, gradually acquiring and processing the data and ensuring its real-time and integrity.

[0119] When the system receives business attribute data from the server, it immediately parses it. This parsing process includes data format conversion and validation. The system then groups the parsed data according to predefined storage rules for subsequent modular storage.

[0120] After the system completes the data grouping process, it packages the grouped data into independent modules. Each module corresponds to a specific data set, and these modularized data will be stored in the Vuex state machine to ensure data sharing and access between different components.

[0121] In one specific implementation, in a bank's multi-account management system, the system divides business attribute data into multiple bands based on account type and transaction frequency. Unlike the basic implementation method, the system in this method dynamically adjusts the time intervals of the bands. For example, for transaction data of high-frequency accounts, the system will shorten the time interval and collect and process data more frequently; for low-frequency accounts, the time interval will be appropriately extended. The system then sends these band data in sequence to the server, and parses and groups the data according to transaction amount and risk level. Finally, the grouped data will be packaged into modules and stored in the Vuex state machine, allowing the system to respond quickly during high-frequency transactions while optimizing the efficiency of data storage and access.

[0122] In another specific embodiment, in the insurance company's claims system, the system divides the business attribute data into multiple bands according to the complexity and urgency of the claims case. The extended technical feature is that the system will combine the artificial intelligence (AI) model to preliminarily classify the claims data. For example, the complexity of the claims case is judged by AI, and the processing order of the data bands is adjusted accordingly. For complex or urgent claims cases, the system will give priority to processing and parsing these data, grouping the data according to the different stages of the case (such as preliminary review and review), and packaging them into independent modules and storing them in the Vuex state machine. In this way, the system can process and respond to the needs of urgent cases in real time, while effectively managing and storing complex claims data.

[0123] This embodiment processes business attribute data according to predetermined rules and time intervals to ensure that data can be organized and stored in a modular form. This not only improves the organization and manageability of the system, but also optimizes data access speed and storage efficiency.

[0124] In one embodiment, in S302 above, parsing the business attribute data and grouping the business attribute data according to predefined storage rules includes:

[0125] S3021, parsing the business attribute data, identifying and extracting business fields in the business attribute data;

[0126] S3022, assigning a corresponding rule number to each business field based on business requirements and predefined storage rules, wherein the rule number is used to guide the grouping and storage of the business fields;

[0127] S3023: Apply corresponding storage rules according to the rule number of each business field, and group the business fields in a modular manner.

[0128] In this embodiment, the system first parses the received business attribute data to identify the various business fields within the data. This step involves data formatting, field identification, and extraction, ensuring that the data can be correctly understood and processed. For example, in an insurance claims system, when receiving claim application data, the system parses the data and identifies key fields such as "Customer Name," "Policy Number," and "Claim Amount." Through parsing, the system can extract these fields and prepare for subsequent grouping and storage.

[0129] Based on business requirements and predefined storage rules, the system assigns a rule number to each identified business field. This number guides subsequent grouping and storage, ensuring that each field is accurately categorized and managed. For example, in a bank's customer management system, the system might assign the number 001 to "Customer Identity Information," 002 to "Account Information," and 003 to "Transaction Records." This numbering allows the system to group and store related fields in corresponding modules for quick access and processing.

[0130] After identification and numbering, the system applies predefined storage rules based on the assigned rule numbers, grouping the business fields into modular blocks. Each block corresponds to a separate storage module, and these modular blocks are ultimately stored in the system for subsequent use. For example, in a financial trading system, the system might separate "high-frequency trading data" from "low-frequency trading data" in different modules based on rule numbers. This optimizes data access speed and improves system processing efficiency.

[0131] In one specific implementation, within a bank's customer relationship management (CRM) system, the system parses and groups business attribute data based on the customer's transaction history and account type. The system introduces an adaptive parsing mechanism that dynamically adjusts the depth and accuracy of data parsing based on the complexity of customer behavior. For high-net-worth customers, the system performs more fine-grained parsing, such as identifying detailed information such as the customer's investment preferences and transaction frequency, and assigning more precise rule numbers to this data. The system then modularly groups the data based on these numbers, such as investment product type and risk preference, thereby providing relationship managers with a more comprehensive and personalized customer profile. This expansion not only improves the accuracy of data parsing, but also enhances the system's ability to serve high-value customers.

[0132] In another specific embodiment, in the insurance company's claims management system, the system will parse the business attribute data according to different claim types and risk levels. The system adopts a multi-level rule numbering system to assign multi-level rule numbers to each business field. For example, for a claim application, the system first assigns a first-level number according to the claim type (such as 001 for auto insurance and 002 for health insurance), and then assigns a second-level number according to the claim amount (such as A for large amounts and B for small amounts). In the data grouping stage, the system not only groups the data according to the first-level number, but also performs more detailed modular storage according to the second-level number. For example, the system will store large auto insurance claims data in a separate module, and small health insurance claims data in another module. This multi-level numbering and grouping method can better support complex claims processing processes and ensure the structuring and efficient management of data.

[0133] By parsing business attribute data and identifying fields, this embodiment enables the system to accurately manage and group data, thereby improving the structured nature of data storage and access efficiency. The method of assigning rule numbers and modular grouping based on storage rules not only simplifies the data management process but also ensures that the system can quickly respond to diverse business needs, improving overall system flexibility and processing performance.

[0134] In one embodiment, after grouping the business fields in a modular manner in S3023, the following steps are further included:

[0135] S3024, selecting a rendering target and output format according to business requirements or user instructions;

[0136] S3025, extracting the grouped and stored business field data from the Vuex state machine, and determining a corresponding rendering template according to the rendering target;

[0137] S3026, binding the extracted business field data to the rendering template, filling the business field data into a specified position of the rendering template, and generating a preliminary rendering result;

[0138] S3027: Format the preliminary rendering result using the output format to obtain a target rendering result.

[0139] In this embodiment, the system selects the appropriate rendering target and output format based on specific business needs or user instructions. The rendering target refers to the type of content to be presented, such as a report, chart, or user interface, while the output format refers to the specific presentation method, such as PDF, HTML, or image file. For example, in a banking system, a relationship manager may need to generate a customer credit assessment report. The rendering target is the credit report, and the output format is PDF, which is convenient for printing and sharing.

[0140] The system extracts the business field data that has been grouped and stored in a modular manner from the Vuex state machine, and then determines the corresponding rendering template based on the selected rendering target. The rendering template is a predefined format structure that contains rules for how the data is displayed in the final output.

[0141] The system binds the extracted business field data to the rendering template and populates the data into the template's designated locations, generating a preliminary rendering result. This step ensures that the data is presented in a structured manner. For example, in a financial transaction system, the system might generate a transaction history report. Transaction data is bound to specific locations in the report template, such as the timeline and amount columns, to generate a preliminary rendering result displaying the customer's transaction history.

[0142] After generating the preliminary rendering results, the system will further format the results according to the specified output format to ensure that the final output rendering results meet the expected format standards and business requirements.

[0143] In one specific implementation, a bank's loan approval system needs to generate different types of approval reports. The system supports multi-target rendering, which generates different rendering targets based on the same dataset. For example, the system can extract customer loan application data from a Vuex state machine and then choose to generate two different rendering targets: a "loan risk assessment report" and a "customer credit summary." The system selects an appropriate rendering template for binding and filling. After generating the preliminary rendering results, it formats the results into PDF and HTML formats to meet different business needs. Multi-target rendering expands the system's application scope, enabling it to more flexibly handle multiple presentation requirements for the same dataset.

[0144] This embodiment, through the selection of rendering targets and templated binding of data, enables the system to generate structured rendering results that meet format requirements based on business needs. This modular rendering process improves the efficiency and customizability of data display, ensuring the high quality and business relevance of the output content. At the same time, through automated formatting, the system significantly improves the speed and consistency of data output, meeting the diverse needs of different business scenarios.

[0145] In one embodiment, the above S301 includes:

[0146] S3011, dividing the business attribute data collected in the centralized variable pool into multiple bands according to preset time intervals;

[0147] S3012, before sending each service data access request, dynamically adjust the sending frequency of the next service data access request according to the current load and network conditions;

[0148] S3013 monitors I / O performance and network conditions in real time and dynamically adjusts the amount of service attribute data sent in each batch;

[0149] S3014, classifying and prioritizing the business data access request based on its urgency and importance;

[0150] S3015 , sending the service data access request for each band to the server in sequence according to the sending frequency of the service data access request, the quantity and priority of the service attribute data sent in each batch.

[0151] In this embodiment, the system divides the business attribute data collected in the centralized variable pool into multiple bands at preset time intervals. These bands represent data accumulated over a certain period of time, and the system will sequentially process and send data access requests for these bands. For example, in a financial system, the system can divide customer transaction records into bands every 10 minutes to gradually process this data and ensure that the system is not overwhelmed by sudden large amounts of data.

[0152] Before sending each business data access request, the system will first dynamically adjust the frequency of the next request based on the current system load and network conditions. If the system load is high or the network conditions are poor, the system may reduce the frequency of requests to prevent excessive use of system resources.

[0153] The system monitors I / O performance and network conditions in real time and dynamically adjusts the amount of business attribute data sent in each batch based on these monitoring results. This maximizes data transmission efficiency without compromising performance. For example, in an insurance claims system, the system might increase the amount of claims data sent in each batch when network conditions are good to accelerate the claims process; when network conditions are poor, the system might reduce the amount of data sent to ensure stable system operation.

[0154] The system categorizes business data access requests based on their urgency and importance, assigning a priority to each request. High-priority requests are prioritized to ensure a quick response to critical business data. For example, in a banking system, a request involving a large funds transfer might be assigned a high priority, while a general account inquiry request might be assigned a lower priority. The system prioritizes high-priority requests to ensure timely completion of funds transfers.

[0155] The system sends service data access requests for each band to the server in sequence based on the transmission frequency, data volume and priority. In this way, the system ensures the orderliness and efficiency of data access requests.

[0156] In one specific implementation, a bank's real-time transaction monitoring system divides business attribute data into multiple bands based on transaction frequency and importance. The system incorporates an adaptive time interval adjustment mechanism, dynamically adjusting the preset time interval based on the intensity of transaction activity. For example, during peak trading periods, the system shortens the time interval to collect and process transaction data more frequently, ensuring timely monitoring of critical transactions. Furthermore, before each data request is sent, the system dynamically adjusts the frequency of requests based on the current server load and network conditions to prevent system overload. Under high load conditions, the system prioritizes high-priority transaction requests and defers other requests until the system load decreases.

[0157] In another specific implementation, an insurance company's claims processing system divides data into bands based on the complexity and urgency of each claim. This system incorporates a predictive scheduling mechanism that analyzes historical data and current case characteristics to predict future system load and network conditions, adjusting transmission frequency and data volume in advance. For example, in anticipation of a large number of claims, the system will reduce the frequency of non-urgent data requests in advance, reserving more resources for critical claims data requests. Furthermore, the system monitors I / O performance in real time and dynamically adjusts the amount of claims data sent in each batch based on the monitoring results, ensuring the system can stably handle peak claims requests.

[0158] This embodiment dynamically adjusts the sending frequency and data volume of data requests, combined with real-time monitoring of system load and network conditions. This method can optimize data transmission efficiency and system resource utilization, while ensuring priority processing of critical business data, thereby improving the stability and response speed of the system in a high-load environment, and ensuring the timeliness and reliability of data access requests.

[0159] The present invention also provides a cross-component data sharing device, referring to Figure 2 , Figure 2 This is a functional module diagram of a preferred embodiment of a cross-component data sharing device of the present invention. The cross-component data sharing device includes:

[0160] Centralized variable pool module, building a centralized variable pool for centralized management and storage of business attribute data, and integrating the Vuex state machine in the centralized variable pool;

[0161] A business attribute collection plug-in module configures a business attribute collection plug-in in a business component, and pushes the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in;

[0162] The data storage and management module stores the business attribute data pushed to the centralized variable pool in the Vuex state machine in a modular manner. The modular storage includes classification and grouping of business attribute data, dividing the data into multiple modules according to different business logics, and defining the access rights and caching strategies of each module;

[0163] The data access and sharing module accesses the centralized variable pool through the business component to realize the sharing of the business attribute data.

[0164] The specific implementation of the cross-component data sharing device of the present invention is basically the same as the various embodiments of the above-mentioned cross-component data sharing method, and will not be repeated here.

[0165] The present invention also provides a cross-component data sharing device, such as Figure 3As shown, the cross-component data sharing device may include: a processor 1001, such as a CPU, a communication bus 1002, a user interface 1003, a network interface 1004, and a memory 1005. Among them, the communication bus 1002 is used to realize the connection and communication between these components. The user interface 1003 may include a display screen (Display), an input unit such as a keyboard (Keyboard), and the user interface 1003 may optionally include a standard wired interface and a wireless interface. The network interface 1004 may optionally include a standard wired interface and a wireless interface (such as a WI-FI interface). The memory 1005 may be a high-speed RAM memory, or a stable memory (non-volatile memory), such as a disk memory. The memory 1005 may optionally be a storage device independent of the aforementioned processor 1001.

[0166] Those skilled in the art will understand that Figure 3 The hardware structure of the cross-component data sharing device shown in the figure does not constitute a limitation to the cross-component data sharing device, and may include more or fewer components than shown in the figure, or combine certain components, or arrange the components differently.

[0167] like Figure 3 As shown, the memory 1005, which serves as a storage medium, may include an operating system, a network communication module, a user interface module, and a cross-component data sharing program. The operating system is a program that manages and controls cross-component data sharing devices and software resources, and supports the operation of the network communication module, the user interface module, the cross-component data sharing program, and other programs or software. The network communication module is used to manage and control the network interface 1004; and the user interface module is used to manage and control the user interface 1003.

[0168] exist Figure 3 In the hardware structure of the cross-component data sharing device shown, the network interface 1004 is mainly used to connect to the background server and communicate data with the background server; the user interface 1003 is mainly used to connect to the client and communicate data with the client; the processor 1001 can call the cross-component data sharing program stored in the memory 1005 and perform the same operations as the cross-component data sharing method.

[0169] The specific implementation of the cross-component data sharing device of the present invention is basically the same as the various embodiments of the above-mentioned cross-component data sharing method, and will not be repeated here.

[0170] In addition, an embodiment of the present invention further provides a computer storage medium on which a cross-component data sharing program is stored. When the cross-component data sharing program is executed by a processor, the steps of the cross-component data sharing method described above are implemented.

[0171] The specific implementation of the computer storage medium of the present invention is basically the same as the embodiments of the above-mentioned cross-component data sharing method, and will not be repeated here.

[0172] The embodiments of the present invention are described above in conjunction with the accompanying drawings, but the present invention is not limited to the above-mentioned specific implementation methods. The above-mentioned specific implementation methods are merely illustrative and not restrictive. Under the guidance of the present invention, ordinary technicians in this field can also make many forms without departing from the scope of protection of the purpose of the present invention and the claims. Any equivalent structure or equivalent process transformation made using the contents of the description and drawings of the present invention, or directly or indirectly used in other related technical fields, all fall within the protection of the present invention.

[0173] In the embodiments provided in this application, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely schematic. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to multiple embodiments of the present application. In this regard, each box in the flowchart or block diagram can represent a module, a program segment or a part of the code, and the module, program segment or a part of the code contains one or more executable instructions for implementing the specified logical functions. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0174] In addition, the functional modules in each embodiment of the present application can be integrated together to form an independent part, or each module can exist separately, or two or more modules can be integrated to form an independent part. If the function is implemented in the form of a software functional module and sold or used as an independent product, it can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present application is essentially or the part that contributes to the prior art or the part of the technical solution can be embodied in the form of a software product, which is stored in a storage medium and includes several instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The aforementioned storage medium includes various media that can store program codes, such as a USB flash drive, a mobile hard disk, a read-only memory (ROM), a random access memory (RAM), a magnetic disk or an optical disk.

[0175] It should be noted that, in this document, relational terms such as first and second, etc., are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply the existence of any such actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variants thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device comprising the element.

[0176] The above descriptions are merely examples of various embodiments of the present application, but the scope of protection of the present application is not limited thereto. Any modifications or substitutions that can be readily conceived by a person skilled in the art within the technical scope disclosed in the present application should be included within the scope of protection of the present application. Therefore, the scope of protection of the present application should be based on the scope of protection of the claims.

Claims

1. A cross-component data sharing method, characterized in that: The following steps are involved: Build a centralized variable pool for centralized management and storage of business attribute data, and integrate the Vuex state machine into the centralized variable pool; Configuring a business attribute collection plug-in in the business component, and pushing the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in; The business attribute data pushed to the centralized variable pool is stored in the Vuex state machine in a modular manner. The modular storage includes classification and grouping of business attribute data, dividing the data into multiple modules according to different business logics, and defining access rights and caching strategies for each module; The centralized variable pool is accessed through business components to achieve sharing of the business attribute data.

2. The cross-component data sharing method according to claim 1, characterized in that: Pushing the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in includes: Setting an anti-shake time threshold, when the business attribute collection plug-in receives a data collection instruction, starts the anti-shake mechanism; If no new data collection instruction is received within the anti-shake time threshold, the business attribute data is pushed from the business component to the centralized variable pool through the business attribute collection plug-in; If a new data collection instruction is received within the anti-shake time threshold, all received data collection instructions are aggregated and merged into one data collection task through the anti-shake mechanism; After the anti-shake time threshold ends, the data collection task is executed by the business attribute collection plug-in, and the corresponding business attribute data is collected from the business component and pushed to the centralized variable pool.

3. The cross-component data sharing method according to claim 1, characterized in that: Accessing the centralized variable pool through business components to achieve sharing of the business attribute data includes: Assigning priorities to business attribute data requests based on the importance of the business attribute data; In the process of the business component initiating a business attribute data request to the centralized variable pool, the business attribute data request is divided into multiple stages according to the assigned priority, and the business attribute data requests in different stages are processed in order of priority; Before the business attribute data request of each stage is sent to the centralized variable pool, a corresponding data request task is generated. The data request task manages and executes the business attribute data request according to priority; After the data request task of each stage is generated and sent to the centralized variable pool, the centralized variable pool receives and processes the business attribute data request of each stage and returns the corresponding business attribute data to the business component.

4. The cross-component data sharing method according to claim 1, wherein: The business attribute data pushed to the centralized variable pool is stored in the Vuex state machine in a modular manner, including: According to a preset time interval, the business attribute data collected in the centralized variable pool is divided into multiple bands, and business data access requests are sent to the server in sequence; After receiving the service attribute data response returned by the server, the service attribute data is parsed and the service attribute data is grouped according to predefined storage rules; The grouped data is packaged into independent modules and stored in the Vuex state machine.

5. The cross-component data sharing method as claimed in claim 4, characterized in that: Parsing the business attribute data and grouping the business attribute data according to predefined storage rules includes: Parsing the business attribute data, identifying and extracting business fields in the business attribute data; According to business requirements and predefined storage rules, each business field is assigned a corresponding rule number, which is used to guide the grouping and storage of business fields; Apply the corresponding storage rule according to the rule number of each business field and group the business fields in a modular manner.

6. The cross-component data sharing method according to claim 5, characterized in that: After grouping business fields in a modular manner, it also includes: Select rendering target and output format based on business needs or user instructions; Extract the grouped and stored business field data from the Vuex state machine, and determine the corresponding rendering template according to the rendering target; Binding the extracted business field data to the rendering template, filling the business field data into a specified position of the rendering template, and generating a preliminary rendering result; The preliminary rendering result is formatted using the output format to obtain a target rendering result.

7. The cross-component data sharing method according to claim 4, characterized in that: According to the preset time interval, the business attribute data collected in the centralized variable pool is divided into multiple bands, and business data access requests are sent to the server in sequence, including: Dividing the business attribute data collected in the centralized variable pool into multiple bands according to preset time intervals; Before sending each business data access request, dynamically adjust the frequency of sending the next business data access request based on the current load and network conditions; Monitor I / O performance and network conditions in real time, and dynamically adjust the amount of business attribute data sent in each batch; Categorize and prioritize business data access requests based on their urgency and importance; The service data access request for each band is sent to the server in sequence according to the sending frequency of the service data access request, the quantity and priority of the service attribute data sent in each batch.

8. A cross-component data sharing device, characterized in that: The cross-component data sharing device includes: Centralized variable pool module, building a centralized variable pool for centralized management and storage of business attribute data, and integrating the Vuex state machine in the centralized variable pool; A business attribute collection plug-in module configures a business attribute collection plug-in in a business component, and pushes the business attribute data in the business component to the centralized variable pool through the business attribute collection plug-in; The data storage and management module stores the business attribute data pushed to the centralized variable pool in the Vuex state machine in a modular manner. The modular storage includes classification and grouping of business attribute data, dividing the data into multiple modules according to different business logics, and defining the access rights and caching strategies of each module; The data access and sharing module accesses the centralized variable pool through the business component to realize the sharing of the business attribute data.

9. A cross-component data sharing device, characterized in that: The cross-component data sharing device includes a memory, a processor, and a cross-component data sharing program stored in the memory and executable on the processor. When the cross-component data sharing program is executed by the processor, the steps of the cross-component data sharing method as described in any one of claims 1 to 7 are implemented.

10. A computer storage medium, characterized in that The storage medium stores a cross-component data sharing program, which, when executed by a processor, implements the steps of the cross-component data sharing method according to any one of claims 1 to 7.

Images