Cross-application collaborative paging query method and device and electronic equipment

Abstract

The invention provides a cross-application collaborative paging query method, a cross-application collaborative paging query device and electronic equipment, which are applied to a main service subsystem in a paging query component at least comprising a main service subsystem and a slave service subsystem. And performing unified data total amount statistics and total paging number calculation on the query result, and performing difference judgment and supplementary combination processing on the data on the master side and the slave side in combination with the display record number of each page under the critical scenes that the current page is located at the last page of the master service subsystem, the last page of the slave service subsystem and the last pages of the master service subsystem and the slave service subsystem are combined. On the premise that the use mode of the existing paging component of the slave service subsystem is not changed, unified paging display of cross-application query results is achieved, repetition and omission of multi-system data in the paging process can be effectively avoided, it is guaranteed that the data between pages is continuous and consistent in number, and the difficulty of paging butt joint and collaboration between multiple systems is lowered.

Description

TECHNICAL FIELD

[0001] The present disclosure relates to the technical field of data query, in particular to a cross-application cooperative paging query method and device and electronic equipment. BACKGROUND

[0002] With the expansion of Internet business scale and the wide application of distributed architecture, enterprise-level application systems generally adopt service splitting and database splitting and other technical means to cope with high concurrency access and mass data storage requirements. In traditional monolithic applications or single data source systems, paging queries usually rely on the offset query of the backend database to cooperate with mainstream paging components to achieve the page display. For example, after receiving the page number and the number of records displayed per page from the front end, the single data source is processed by PageHelper and other components, and the results are returned to the front end for display. This kind of solution can basically meet the business requirements in the scene where the data source is single and the system size is small.

[0003] However, in the business environment of micro-service and multi-system cooperation, the same business query often needs to access multiple application systems or multiple data sources at the same time, such as sales management, policy management, customer information, etc. The data is scattered in different subsystems, but the front end wants to display it in a unified page form. The existing mainstream paging components are mostly designed for single application and single data source, and only focus on the paging logic of the local result set, and do not provide a unified control mechanism for cross-application and multi-data source cooperative paging. In the case where multiple subsystems participate in the same paging query, how to coordinate the data volume statistics, paging boundary calculation and last page display rules between different systems without changing the usage of the existing paging components of each subsystem is still a difficult problem in the prior art. SUMMARY

[0004] The embodiments of the present disclosure at least provide a cross-application cooperative paging query method, device and electronic equipment, by introducing a cooperative paging control mechanism in the main business subsystem, unified data total statistics and paging total page calculation are performed on the query results of the main and slave business subsystems, and in the critical scene where the current page is located in the last page of the main business subsystem, the last page of the slave business subsystem and the last page of the combination of the two, combined with the number of records displayed per page, the difference between the main and slave data is judged and supplemented and merged, without changing the usage of the existing paging components of the slave business subsystem, the unified paging display of the cross-application query results is realized, which can effectively avoid the repetition and omission of multi-system data in the paging process, ensure the data continuity and consistency between pages, and keep transparent to the front end, simplifying the paging connection and cooperation difficulty between multiple systems.

[0005] The embodiment of the present disclosure provides a cross-application cooperative paging query method, which is applied to a main business subsystem in a paging query component including at least the main business subsystem and a slave business subsystem, and the method comprises the following steps: In response to a paging query request of a front-end system, first query data meeting a query condition is queried in a local data source, and a slave business subsystem is called to query second query data meeting the query condition in a corresponding data source; The total amount of the queried data is counted, the total number of pages is determined according to the total amount of data and the number of records per page carried in the paging query request, and a paging operation is performed on the first query data according to the number of records per page; In the process of the paging operation, if the page number currently input by the front-end system falls on a first last page of the first query data corresponding to the number of pages, and the data amount of the first last page is insufficient for the number of records per page, the first query data of the first last page is temporarily discarded, the paging operation is performed on the second query data by calling the slave business subsystem, and the data paging result is returned to the front-end system for display; When the slave business subsystem is paging processed to a second last page of the second query data corresponding to the number of pages, if the data amount of the second last page is insufficient for the number of records per page, the page difference data amount of the second last page is determined according to the number of records per page, the required supplement data amount of the first last page is determined according to the size relationship between the page difference data amount and the data amount of the first last page, and the first query data of the required supplement data amount and the second query data of the second last page are merged and returned to the front-end system for display.

[0006] In an optional implementation, the required supplement data amount of the first last page is determined according to the size relationship between the page difference data amount and the data amount of the first last page, and the first query data of the required supplement data amount and the second query data of the second last page are merged and returned to the front-end system for display, and specifically comprising the following steps: When the data amount of the first last page is greater than the page difference data amount, a difference value between the number of records per page and the page difference data amount is determined as the required supplement data amount, the first query data corresponding to the required supplement data amount in the first last page is intercepted, and the first query data and the second query data in the second last page are merged and returned to the front-end system for display; When the data amount of the first last page is less than the page difference data amount, the data amount of the first last page is taken as the required supplement data amount, and the first query data in the first last page and the second query data of the second last page are merged and returned to the front-end system for display.

[0007] In an optional implementation, after merging the first query data requiring supplementation with the second query data from the second last page and returning it to the front-end system for display, the method further includes: When the sum of the data volume of the first last page and the data volume of the second last page is greater than the number of records displayed per page, the page number requested by the front-end system corresponds to the second to last page of the total number of pages. When the front-end system requests to display the last page of the total number of pages, the data volume of the second last page is deducted from the first query data in the first last page, and the result is returned to the front-end system as the last page of the total number of pages.

[0008] In one optional implementation, the method further includes: When the amount of data on the first last page is less than the number of records displayed per page, the difference in the amount of data between the amount of data on the first last page and the number of records displayed per page is determined. The starting and ending positions of the second query data that needs to be queried in the business subsystem are determined based on the data volume difference. The starting position and the ending position are sent as query parameters to the slave business subsystem, and the second query data returned by the slave business subsystem from the local data source according to the query parameters is received. The first query data on the first last page is merged with the second query data returned by the business subsystem from the local data source according to the query parameters, and then returned to the front-end system for display.

[0009] In one optional implementation, after calculating the total amount of data retrieved and determining the total number of pages based on the total amount of data and the number of records displayed per page carried in the pagination query request, the method further includes: If the first query data does not exist but the second query data does exist, then the business subsystem is directly invoked to perform pagination on the second query data and then returned to the front-end system for display. If the second query data does not exist but the first query data does exist, then the pagination operation is performed directly on the first query data and the system is returned to display the data.

[0010] In one optional implementation, during the pagination operation performed by the business subsystem on the second query data, if the amount of data on the second last page meets the number of records displayed per page, then the second query data on the second last page is directly returned to the front-end system as the second to last page of the total number of pages for display. The prime number query data of the first last page is returned to the front-end system as the last page of the total number of pages for display.

[0011] In one optional implementation, during the pagination operation on the first query data: If the page number passed to the front-end system does not fall on the first last page of the pageable number of the first query data, then the first query data on that page will be directly returned to the front-end system for display.

[0012] This disclosure also provides a cross-application collaborative pagination query device, applied to the main business subsystem in a pagination query component that includes at least one main business subsystem and one slave business subsystem. The device includes: The query triggering module is used to respond to the pagination query request of the front-end system, query the first query data that meets the query conditions in the local data source, and call the business subsystem to query the second query data that meets the query conditions in the corresponding data source. The first pagination module is used to count the total amount of data retrieved, determine the total number of pages based on the total amount of data and the number of records displayed per page carried in the pagination query request, and perform pagination operation on the first query data based on the number of records displayed per page. The second pagination module is used to temporarily discard the first query data on the first last page of the first query data if, during the pagination operation, the page number passed by the current front-end system falls on the first last page of the number of pages that can be paginated for the first query data, and the amount of data on the first last page is less than the number of records to be displayed per page. Then, the module calls the business subsystem to perform the pagination operation on the second query data and returns the data pagination result to the front-end system for display. The last page supplementation module is used to determine the page difference data amount of the second last page when the pagination process from the business subsystem reaches the second last page corresponding to the number of pages that can be paginated for the second query data. If the data amount of the second last page is less than the number of records displayed per page, the module determines the page difference data amount of the second last page based on the number of records displayed per page. Based on the relationship between the page difference data amount and the data amount of the first last page, the module determines the amount of supplementary data needed for the first last page. The module then merges the first query data with the second query data of the second last page and returns it to the front-end system for display.

[0013] This disclosure also provides an electronic device, including: a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, they perform the steps of the above-described cross-application collaborative paging query method, or any possible implementation of the above-described cross-application collaborative paging query method.

[0014] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the cross-application collaborative paging query method described above, or any possible implementation of the cross-application collaborative paging query method described above.

[0015] This disclosure also provides a computer program product, including a computer program / instruction, which, when executed by a processor, implements the above-described cross-application collaborative paging query method, or the steps in any possible implementation of the above-described cross-application collaborative paging query method.

[0016] This disclosure provides a cross-application collaborative pagination query method, apparatus, and electronic device, applied to the main business subsystem in a pagination query component comprising at least one main business subsystem and one slave business subsystem. By introducing a collaborative pagination control mechanism into the main business subsystem, the total data volume and total number of pages are uniformly counted for the query results of the main and slave business subsystems. In critical scenarios such as the current page being the last page of the main business subsystem, the last page of the slave business subsystem, or the last pages of both being merged, the difference judgment and supplementary merging processing of the data on both the main and slave sides are performed based on the number of records displayed per page. Without changing the usage of the existing pagination component in the slave business subsystem, unified pagination display of cross-application query results is achieved. This effectively avoids duplication and omission of data from multiple systems during the pagination process, ensures data continuity and consistency between pages, and maintains transparency to the front end, simplifying the pagination connection and collaboration between multiple systems.

[0017] To make the above-mentioned objects, features and advantages of this disclosure more apparent and understandable, preferred embodiments are described below in detail with reference to the accompanying drawings. Attached Figure Description

[0018] To more clearly illustrate the technical solutions of the embodiments of this disclosure, the accompanying drawings used in the embodiments will be briefly described below. These drawings are incorporated in and constitute a part of this specification. They illustrate embodiments conforming to this disclosure and, together with the specification, serve to explain the technical solutions of this disclosure. It should be understood that the following drawings only show some embodiments of this disclosure and should not be considered as limiting the scope. Those skilled in the art can obtain other related drawings based on these drawings without creative effort.

[0019] Figure 1 A flowchart of a cross-application collaborative pagination query method provided in an embodiment of this disclosure is shown; Figure 2 A flowchart is shown for another cross-application collaborative pagination query method provided in an embodiment of this disclosure; Figure 3 A schematic diagram of a cross-application collaborative pagination query device provided in an embodiment of this disclosure is shown; Figure 4 A schematic diagram of an electronic device provided in an embodiment of this disclosure is shown. Detailed Implementation

[0020] To make the objectives, technical solutions, and advantages of the embodiments of this disclosure clearer, the technical solutions of the embodiments of this disclosure will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this disclosure, and not all of them. The components of the embodiments of this disclosure described and shown in the accompanying drawings can generally be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of this disclosure provided in the accompanying drawings is not intended to limit the scope of the claimed disclosure, but merely represents selected embodiments of this disclosure. All other embodiments obtained by those skilled in the art based on the embodiments of this disclosure without inventive effort are within the scope of protection of this disclosure.

[0021] It should be noted that similar labels and letters in the following figures indicate similar items. Therefore, once an item is defined in one figure, it does not need to be further defined and explained in subsequent figures.

[0022] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0023] Research has revealed that in microservice-based and multi-system collaborative business environments, the same business query often requires simultaneous access to multiple application systems or data sources. For example, data from sales management, policy management, and customer information are scattered across different subsystems, yet the front-end expects to display them in a unified pagination format. Existing mainstream pagination components are mostly designed for single applications and single data sources, focusing only on the pagination logic of local result sets and failing to provide a unified control mechanism for cross-application, multi-data source collaborative pagination. When multiple subsystems participate in the same pagination query simultaneously, coordinating data volume statistics, pagination boundary calculations, and last page display rules across different systems without altering the existing usage of pagination components remains a common challenge in current technologies.

[0024] Based on the above research, this disclosure provides a cross-application collaborative pagination query method, apparatus, and electronic device, applied to the main business subsystem in a pagination query component comprising at least one main business subsystem and one slave business subsystem. By introducing a collaborative pagination control mechanism into the main business subsystem, the total data volume and total number of pages are uniformly counted for the query results of the main and slave business subsystems. In critical scenarios such as the current page being the last page of the main business subsystem, the last page of the slave business subsystem, or the last pages of both being merged, the difference judgment and supplementary merging processing of the data on the main and slave sides are performed based on the number of records displayed per page. Without changing the usage of the existing pagination component in the slave business subsystem, unified pagination display of cross-application query results is achieved. This effectively avoids duplication and omission of data from multiple systems during the pagination process, ensures data continuity and consistency between pages, and maintains transparency to the front end, simplifying the pagination connection and collaboration between multiple systems.

[0025] To facilitate understanding of this embodiment, a cross-application collaborative pagination query method disclosed in this disclosure will first be described in detail. The execution entity of the cross-application collaborative pagination query method provided in this disclosure is the main business subsystem within a pagination query component that includes at least one main business subsystem and one slave business subsystem. The main business subsystem integrates the collaborative pagination query logic proposed in this invention. Upon receiving a pagination query request initiated by the front-end system, it uniformly performs local data query, remotely calls the slave business subsystem, counts the total data volume of the query results on both the main and slave sides, calculates the total number of pages, determines the data range of the current page, and, in boundary scenarios such as a specific page number falling into the last page of the pagination range of the main business subsystem, the last page of the pagination range of the slave business subsystem, or the merging of the last pages of both, performs difference calculation and supplementary merging processing on the data on both the main and slave sides based on the number of records displayed per page. Finally, the processed pagination results are returned to the front-end system for display. Corresponding to the main business subsystem, the slave business subsystem is a business subsystem that performs pagination operations using existing pagination components. The secondary business subsystem can be an application system deployed independently of the primary business subsystem. Internally, it uses existing pagination implementations, such as integrating mainstream pagination components like PageHelper, to perform traditional pagination processing on query results from its local data source. In the collaborative pagination process of this invention, the secondary business subsystem does not change its existing pagination invocation method, nor is it responsible for cross-system data coordination and page number calculation. Instead, based on the pagination request or query instruction carrying parameters such as start and end positions issued by the primary business subsystem, it executes the corresponding pagination query or range query operation in its own local data source and returns the obtained second query data as a pagination result fragment to the primary business subsystem. The primary business subsystem then further concatenates, completes, and organizes the page relationships with the first query data. In some possible implementations, this cross-application collaborative pagination query method can be implemented by the processor calling computer-readable instructions stored in memory.

[0026] See Figure 1 The diagram shows a flowchart of a cross-application collaborative pagination query method provided in an embodiment of this disclosure. The method includes steps S101 to S104, wherein: S101. In response to the pagination query request from the front-end system, query the first query data that meets the query conditions in the local data source, and call the business subsystem to query the second query data that meets the query conditions in the corresponding data source.

[0027] In practice, when the front-end system needs to display target business data in pages, it first sends a page query request to the main business subsystem. This page query request must include at least the query conditions used to limit the range of target data, as well as parameters such as the page number and the number of records displayed per page for page control.

[0028] Here, after receiving a pagination query request from the front-end system, the main business subsystem parses the query conditions carried in the request, applies the parsed query conditions to its local data source, performs the corresponding retrieval operation in the local data source, and retrieves the first query data that meets the query conditions.

[0029] The local data source can be a database or other persistent storage that is deployed and bound to the main business subsystem. The first query data is a set of local query results that fully meet the query conditions without considering specific pagination.

[0030] Furthermore, after completing the query of the local data source, in order to obtain data that meets the same query conditions in other systems in a cross-application environment, the main business subsystem also initiates a remote call to the slave business subsystem through a pre-agreed service call interface based on the query conditions in the same pagination query request sent by the front-end system, requesting the slave business subsystem to perform condition retrieval in its corresponding data source that is consistent with the local query of the main business subsystem.

[0031] Here, after receiving a call request from the main business subsystem, the business subsystem applies the query conditions forwarded or encapsulated by the main business subsystem to its corresponding data source, performs a query operation on the data source, obtains second query data that meets the query conditions, and returns the second query data as the query result to the main business subsystem.

[0032] In this way, when the main business subsystem responds to a front-end pagination query request, it obtains the first query data from its own local data source and obtains the second query data from its corresponding data source by calling the slave business subsystem. This lays the foundation for subsequent total data statistics, total number of pagination pages calculation, and collaborative pagination display of the query results from both the main and slave subsystems.

[0033] S102. Calculate the total amount of data retrieved, determine the total number of pages based on the total amount of data and the number of records displayed per page carried in the pagination query request, and perform pagination operation on the first query data based on the number of records displayed per page.

[0034] In practice, after obtaining the first and second query data, the main business subsystem further performs statistical processing on the query results. Specifically, the main business subsystem obtains the number of records of the first query data obtained from the local data source and the number of records of the second query data obtained from the corresponding data source of the business subsystem, and sums the two to obtain the total amount of query data for this business query across the application scope.

[0035] Here, after obtaining the total amount of query data, the main business subsystem combines the number of records displayed per page carried by the front-end system in the pagination query request to evaluate the pagination capability of the total amount. That is, the total amount of query data is divided into whole pages according to the number of records displayed per page. When there is a remainder that cannot be divided evenly, the remainder is taken as the amount of data in the last page, thereby determining the total number of pages in this query.

[0036] It should be noted that the total number of pages in the pagination can be used for the front-end page's pagination control display, and also serves as the basis for subsequent determination of whether the current page is at the pagination boundary and whether cross-system data supplementation is involved.

[0037] Furthermore, after determining the total number of pages, the main business subsystem will also perform specific pagination operations on the first query data obtained from the local data source, based on the same number of records displayed per page. The main business subsystem will sequentially split the first query data according to the number of records displayed per page, dividing the first query data into several pages, with each page corresponding to a set of local data records available for front-end display.

[0038] Here, during this process, the main business subsystem can simultaneously determine the number of pages that the first query data can be generated locally and the corresponding last page position, providing a basis for subsequently determining whether the page number passed in by the front end falls on the first or last page of the number of pages that the first query data can be divided into.

[0039] In this way, by calculating the total amount of data retrieved through the above statistical queries, calculating the total number of pages, and performing pagination on the first query data according to the number of records displayed per page, the main business subsystem lays a unified pagination baseline for subsequent collaborative pagination with the secondary business subsystems, data completion on the last page, and cross-system data merging without changing the original data storage structure.

[0040] As one possible implementation, if the first query data does not exist but the second query data does exist, the business subsystem is directly invoked to perform pagination on the second query data and then returned to the front-end system for display; if the second query data does not exist but the first query data exists, the first query data is directly paginated and then returned to the front-end system for display.

[0041] In specific implementation, this application embodiment also handles the situation where only one side of the system has query results, in order to avoid executing unnecessary collaborative pagination logic when one side of the system has no data. Specifically, after the main business subsystem completes the query and quantity statistics of the first query data and the second query data, it first determines whether there is first query data that meets the query conditions in the local data source and whether there is second query data that meets the query conditions in the corresponding data source of the business subsystem.

[0042] Here, when the judgment result is that the first query data does not exist but the second query data does exist, it means that all the data to be displayed in this business query comes from the side of the secondary business subsystem. In this case, the main business subsystem does not need to perform pagination display operations on the local data source. Instead, it directly delegates the pagination request to the secondary business subsystem. The secondary business subsystem uses its integrated existing pagination component to perform local pagination operations on the second query data, generates the corresponding page data records according to the number of records to be displayed per page, and returns the pagination result to the main business subsystem. The main business subsystem then forwards it to the front-end system for display as is. Thus, pagination query and display of a single system can be achieved when only the secondary business subsystem has data.

[0043] Correspondingly, when the judgment result is that the second query data does not exist but the first query data exists, it means that the data to be displayed in this business query is completely stored in the local data source of the main business subsystem. In this case, the main business subsystem does not need to remotely call the secondary business subsystem to participate in collaborative pagination processing. Instead, based on the previously determined number of records to be displayed per page and the total number of pages, it directly performs pagination operation on the first query data, selects the local data record set corresponding to the current page number to form the display data of the current page, and directly returns the first query data of the page to the front-end system for display.

[0044] Thus, through the above branching process, the method of the present invention can automatically degenerate into a single-system pagination mode when only the main business subsystem or only the secondary business subsystem has query results. This avoids meaningless cross-system calls and complex merging logic, while maintaining the consistency of the front-end calling method, and ensuring the simplicity and rationality of the pagination process under different data distribution scenarios.

[0045] S103. During the pagination operation, if the page number passed by the current front-end system falls on the first last page of the number of pages corresponding to the first query data, and the amount of data on the first last page is insufficient for the number of records displayed per page, then the first query data on the first last page is temporarily discarded, and the business subsystem is called to perform the pagination operation on the second query data and return the data pagination result to the front-end system for display.

[0046] In practice, during the pagination operation for the first query data, the main business subsystem does not simply return the data of the corresponding page mechanically according to the number of records displayed per page, but rather determines the position of the page number passed in by the front-end system by combining the number of paginated pages that can be formed locally from the first query data.

[0047] Here, when the main business subsystem determines that the page number passed in by the front-end system falls exactly on the first last page of the pageable number of the first query data, that is, the current page has reached the last page that the main business subsystem's local data can support, and further determines that the actual amount of data contained in the first last page is less than the number of records displayed per page and cannot independently constitute a whole page of display data, the main business subsystem does not immediately return the first query data, which is less than a page, directly to the front-end system as the result of the current page. Instead, it temporarily discards this part of the data and keeps the first query data corresponding to the first last page locally without participating in the display output of the current page.

[0048] After completing the above judgment and temporary abandonment operations, the main business subsystem then transfers the responsibility of pagination processing of the current page to the secondary business subsystem. That is, the main business subsystem sends a pagination request for the second query data to the secondary business subsystem based on the current page number and the number of records displayed per page, instructing the secondary business subsystem to perform the same pagination operation on the second query data in its local data source as the front-end request.

[0049] Here, after receiving the pagination request, the business subsystem uses its existing integrated pagination component to paginate the second query data, selects the second query data record set corresponding to the current page as the pagination result and returns it to the main business subsystem. The main business subsystem then forwards the pagination result returned by the business subsystem to the front-end system for display.

[0050] In this way, by not returning the local data for the insufficient page when the last page of the first query data is insufficient, but instead completing the display of the current page from the business subsystem first, space is reserved for supplementing and merging the data from the first last page when paginating from the business subsystem to its second last page. This helps to maintain the continuity and integrity between cross-system data pages within the overall pagination scope.

[0051] It should be noted that during the pagination operation for the first query data: if the page number passed by the current front-end system does not fall on the first or last page of the pageable number of the first query data, the first query data of that page will be directly returned to the front-end system for display.

[0052] S104. When the pagination process from the business subsystem reaches the second last page corresponding to the number of pages that can be paginated for the second query data, if the amount of data on the second last page is less than the number of records displayed per page, the amount of page difference data for the second last page is determined based on the number of records displayed per page. Based on the relationship between the amount of page difference data and the amount of data on the first last page, the amount of data to be supplemented on the first last page is determined. The first query data of the amount of data to be supplemented is then merged with the second query data of the second last page and returned to the front-end system for display.

[0053] During the pagination operation of the second query data performed by the business subsystem in the aforementioned manner, when the business subsystem completes the pagination process page by page and advances to the second last page corresponding to the number of pages that the second query data can be paginated, the main business subsystem receives and knows the actual amount of the second query data contained in the second last page, and determines whether the amount of data meets the number of records to be displayed per page.

[0054] In practice, when the judgment result is that the amount of data on the second and last pages is insufficient to display the number of records per page, that is, the second and last pages cannot constitute a complete page of data to be displayed, the main business subsystem does not directly return the second query data that is insufficient to fill a page as the current page to the front-end system. Instead, it calculates the page difference data amount of the second and last pages based on the number of records to be displayed per page. That is, it subtracts the amount of data already in the second and last pages from the number of records to be displayed per page, thereby obtaining the number of data records that still need to be supplemented on the current page.

[0055] Here, after obtaining the amount of page difference data, the main business subsystem further compares the amount of page difference data with the amount of first query data contained in the first last page that was temporarily discarded locally. Based on the relationship between the two, it determines the amount of first query data that actually needs to be supplemented for display in the first last page. On this basis, it selects the corresponding number of first query data from the first last page and merges them with the existing second query data in the second last page to form a complete display dataset that meets the requirement of displaying the number of records per page. Then, the main business subsystem returns the merged page data to the front-end system for unified display.

[0056] In this way, through this process, in the scenario of displaying the last page across master and slave business subsystems, the remaining data on both sides can be fully utilized to fill in the gaps, ensuring that the number of records on the last page is consistent with that on ordinary pages, and avoiding problems such as insufficient data on one page or discontinuous distribution.

[0057] Specifically, when the amount of data on the first last page is greater than the amount of data in the page difference, the difference between the number of records displayed per page and the amount of data in the page difference is determined as the amount of data to be supplemented. The first query data corresponding to the amount of data to be supplemented is extracted from the first last page and merged with the second query data from the second last page before being returned to the front-end system for display. When the amount of data on the first last page is less than the amount of data in the page difference, the amount of data on the first last page is taken as the amount of data to be supplemented, and the first query data from the first last page is merged with the second query data from the second last page before being returned to the front-end system for display.

[0058] In the specific implementation process, the main business subsystem determines the amount of page difference data for the second last page based on the number of records displayed per page, and then compares this amount of page difference data with the amount of data for the first last page to further refine and determine the amount of first query data that actually needs to be displayed in the first last page.

[0059] Here, when the comparison result shows that the amount of data on the first last page is greater than the amount of data between the pages, the main business subsystem uses the difference between the number of records displayed per page and the amount of data between the pages as the amount of data to be supplemented. It then extracts the number of records corresponding to the amount of data to be supplemented from the first query data on the first last page according to a preset order rule. The extracted first query data is then merged with the existing second query data on the second last page to form a complete display data that meets the requirement of the number of records displayed per page, and then returned to the front-end system for display.

[0060] Here, when the comparison result shows that the amount of data on the first last page is less than the amount of data in the page difference, the main business subsystem will directly treat the actual amount of data on the first last page as the amount of data to be supplemented. Instead of further filtering from the first last page, it will merge all the first query data in the first last page with the second query data in the second last page. The merged result will be returned to the front-end system as the display data of the current page. In this way, by supplementing the data under the above two different size relationships, the system can adapt to the cross-system last page data splicing requirements under different combinations of the first last page data amount and the page difference data amount.

[0061] As one possible implementation, when the sum of the data volume of the first last page and the data volume of the second last page is greater than the number of records displayed per page, the page number requested by the front-end system corresponds to the second to last page of the total number of pages. When the front-end system requests to display the last page of the total number of pages, the data volume of the second last page is deducted from the first query data in the first last page, and the result is returned to the front-end system as the last page of the total number of pages.

[0062] In practical implementation, during the process of supplementing and merging the data on the first and second last pages, there is a situation where the sum of the data volume on the first and second last pages exceeds the number of records displayed per page. To address this, this invention considers the current page of data formed based on the amount of data to be supplemented as the second-to-last page in the total number of pages; that is, the page number requested by the current front-end system corresponds to the second-to-last page in the total number of pages.

[0063] In other words, in this scenario, there is still more than one page of records left unused on the first and second last pages. The current page of data, which is formed by merging part of the first and second query data, is only returned to the front-end system as the second to last page for display.

[0064] Here, when the front-end system makes another request to display the last page of the total number of pages, the main business subsystem no longer calls the secondary business subsystem to perform a new pagination query. Instead, based on the previously known data volume relationship between the first and second last pages, it subtracts the data volume corresponding to the second query data that has already been displayed on the second-to-last page from the first query data already present on the first last page, and returns the remaining first query data as the last page data of the entire total number of pages to the front-end system for display.

[0065] In this way, when the total amount of data on the first and second last pages exceeds the single-page display limit, the excess data is naturally distributed to the penultimate and last pages. This ensures that the amount of data on each page meets the requirement for the number of records displayed per page, while maintaining the continuity of the record order and the consistency of the overall pagination logic during the splitting and combining of the last two pages of data across systems.

[0066] As another possible implementation, during the pagination operation performed on the second query data from the business subsystem, if the amount of data on the second last page meets the number of records displayed per page, then the second query data on the second last page is directly returned to the front-end system as the second to last page of the total number of pages; the prime number first query data on the first last page is returned to the front-end system as the last page of the total number of pages.

[0067] In practice, during the pagination operation performed by the business subsystem on the second query data, the main business subsystem also handles whether the amount of data on the last page of the second pagination corresponding to the second query data exactly meets the number of records displayed per page.

[0068] Here, when the pagination process from the business subsystem reaches the second last page, if the amount of data in the second last page is equal to the number of records displayed per page, that is, the second last page itself constitutes a complete page of display data, then the main business subsystem does not need to introduce the first query data to supplement it on this page. Instead, it directly returns the entire page result corresponding to the second query data in the second last page as the second to last page in the total number of pages to the front-end system for display.

[0069] Subsequently, when the front-end system continues to send requests to display the last page in the total number of pages, the main business subsystem retrieves the corresponding first query data from the previously temporarily discarded first last page and returns all the first query data in the first last page as the last page in the total number of pages to the front-end system for display.

[0070] In this way, with the amount of data on the second and last pages exactly equal to the number of records displayed per page, the penultimate page consists entirely of the second query data from the business subsystem, while the last page consists entirely of the first query data from the main business subsystem. The entire pagination process does not require data splitting and re-joining between the last two pages, simplifying the collaborative logic when displaying the last two pages across systems, while ensuring the integrity and continuity of data display at the pagination boundaries.

[0071] This disclosure provides a cross-application collaborative pagination query method, applied to the main business subsystem in a pagination query component comprising at least one main business subsystem and one slave business subsystem. By introducing a collaborative pagination control mechanism into the main business subsystem, the method performs unified total data statistics and pagination total number calculations on the query results of the main and slave business subsystems. In critical scenarios such as the current page being the last page of the main business subsystem, the last page of the slave business subsystem, or the last pages of both being merged, the method performs difference judgment and supplementary merging processing on the data on both the main and slave sides based on the number of records displayed per page. Without changing the usage of the existing pagination component in the slave business subsystem, this method achieves unified pagination display of cross-application query results, effectively avoiding duplication and omission of data from multiple systems during the pagination process, ensuring data continuity and consistency between pages, while maintaining transparency to the front end, and simplifying the pagination connection and collaboration between multiple systems.

[0072] See Figure 2 The diagram shows a flowchart of another cross-application collaborative pagination query method provided in this embodiment of the present disclosure. The method includes steps S201 to S204, wherein: S201. When the amount of data on the first last page is less than the number of records displayed per page, determine the difference in data amount between the amount of data on the first last page and the number of records displayed per page.

[0073] S202. Determine the start and end positions of the second query data that needs to be queried in the business subsystem based on the data volume difference.

[0074] S203. Send the start position and the end position as query parameters to the slave business subsystem, and receive the second query data returned by the slave business subsystem from the local data source according to the query parameters.

[0075] S204. The first query data on the first last page is merged with the second query data returned by the business subsystem from the local data source according to the query parameters, and then returned to the front-end system for display.

[0076] In another embodiment of the present invention, when the main business subsystem performs pagination on the first query data in the local data source, if it detects that the amount of first query data actually contained in the first last page is less than the number of records displayed per page, that is, the first last page itself is insufficient to constitute a whole page of displayed data, the main business subsystem first calculates the data volume difference that needs to be supplemented by other systems based on the difference between the amount of data in the first last page and the number of records displayed per page. Specifically, the main business subsystem uses the number of records displayed per page as a benchmark, subtracts the number of data entries currently actually contained in the first last page from the number of records displayed per page, and obtains a data volume difference, which is used to represent the number of second query data entries that still need to be supplemented from the business subsystem side in the current page.

[0077] Here, after determining the data volume difference, the main business subsystem further calculates the start and end positions of the second query data to be queried in the secondary business subsystem by combining the arrangement order of the second query data in the overall pagination. The main business subsystem can regard the aforementioned data volume difference as the number of data records to be supplemented on the secondary business subsystem side, and based on the known total amount of the second query data and its positional relationship in the global dataset, determine a clear data range to identify the starting and ending records to be extracted from the second query data.

[0078] Subsequently, the main business subsystem encapsulates the determined start and end positions as query parameters in a remote call request and sends it to the slave business subsystem. The slave subsystem is then requested to perform a query operation on its local data source according to this range, retrieving the corresponding amount of second query data. Upon receiving the query request carrying the start and end position parameters, the slave business subsystem searches its local data source according to this range and returns the retrieved second query data to the main business subsystem.

[0079] Here, after receiving the second query data returned by the business subsystem based on the start and end positions, the main business subsystem merges this second query data with the original first query data on the last page. By concatenating the first query data on the last page with the second query data precisely extracted from the business subsystem based on the data volume difference, a complete data set is formed. This ensures that the number of data entries after merging exactly meets the requirement for the number of records displayed per page, thus constituting a complete page of paginated display data.

[0080] Ultimately, the main business subsystem returns the merged page data to the front-end system as the display result of the current page. This achieves cross-system last page completion and unified display by precisely controlling the data range supplemented from the business subsystem when the last page data in the main business subsystem is less than one page.

[0081] This disclosure provides a cross-application collaborative pagination query method, applied to the main business subsystem in a pagination query component comprising at least one main business subsystem and one slave business subsystem. By introducing a collaborative pagination control mechanism into the main business subsystem, the method performs unified total data statistics and pagination total number calculations on the query results of the main and slave business subsystems. In critical scenarios such as the current page being the last page of the main business subsystem, the last page of the slave business subsystem, or the last pages of both being merged, the method performs difference judgment and supplementary merging processing on the data on both the main and slave sides based on the number of records displayed per page. Without changing the usage of the existing pagination component in the slave business subsystem, this method achieves unified pagination display of cross-application query results, effectively avoiding duplication and omission of data from multiple systems during the pagination process, ensuring data continuity and consistency between pages, while maintaining transparency to the front end, and simplifying the pagination connection and collaboration between multiple systems.

[0082] Those skilled in the art will understand that, in the above-described method of the specific implementation, the order in which each step is written does not imply a strict execution order and does not constitute any limitation on the implementation process. The specific execution order of each step should be determined by its function and possible internal logic.

[0083] Based on the same inventive concept, this disclosure also provides a cross-application collaborative pagination query device corresponding to the cross-application collaborative pagination query method. It is applied to the main business subsystem in a pagination query component that includes at least one main business subsystem and one slave business subsystem. Since the principle of the device in this disclosure for solving the problem is similar to the cross-application collaborative pagination query method described above in this disclosure, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0084] Please see Figure 3 , Figure 3 This is a schematic diagram of a cross-application collaborative pagination query device provided in an embodiment of this disclosure. Figure 3 As shown in the figure, the cross-application collaborative pagination query device 300 provided in this embodiment includes: The query triggering module 310 is used to respond to the pagination query request of the front-end system, query the first query data that meets the query conditions in the local data source, and call the business subsystem to query the second query data that meets the query conditions in the corresponding data source.

[0085] The first pagination module 320 is used to count the total amount of data retrieved, determine the total number of pages based on the total amount of data and the number of records displayed per page carried in the pagination query request, and perform pagination operations on the first query data based on the number of records displayed per page. The second pagination module 330 is used to temporarily discard the first query data on the first last page of the first query data if, during the pagination operation, the page number passed by the current front-end system falls on the first last page of the number of pages that can be paginated for the first query data, and the amount of data on the first last page is less than the number of records to be displayed per page. Then, the module calls the business subsystem to perform the pagination operation on the second query data and returns the data pagination result to the front-end system for display.

[0086] The last page supplementation module 340 is used to determine the page difference data amount of the second last page when the pagination processing from the business subsystem reaches the second last page corresponding to the number of pages that can be paginated for the second query data. If the data amount of the second last page is less than the number of records displayed per page, the module determines the page difference data amount of the second last page based on the number of records displayed per page. Based on the relationship between the page difference data amount and the data amount of the first last page, the module determines the amount of supplementary data to be added to the first last page. The module then merges the first query data of the supplementary data amount with the second query data of the second last page and returns it to the front-end system for display.

[0087] The processing flow of each module in the device and the interaction flow between each module can be referred to the relevant descriptions in the above method embodiments, and will not be detailed here.

[0088] This disclosure provides a cross-application collaborative pagination query device, applied to the main business subsystem in a pagination query component comprising at least one main business subsystem and one slave business subsystem. By introducing a collaborative pagination control mechanism into the main business subsystem, the device performs unified total data statistics and pagination total number calculations on the query results of the main and slave business subsystems. In critical scenarios such as the current page being the last page of the main business subsystem, the last page of the slave business subsystem, or the last pages of both being merged, the device performs difference judgment and supplementary merging processing on the data on both the main and slave sides based on the number of records displayed per page. Without changing the usage of the existing pagination component in the slave business subsystem, the device achieves unified pagination display of cross-application query results, effectively avoiding duplication and omission of data from multiple systems during the pagination process, ensuring data continuity and consistency between pages, while maintaining transparency to the front end, and simplifying the pagination connection and collaboration between multiple systems.

[0089] Corresponding to Figure 1 and Figure 2 In addition to the cross-application collaborative pagination query method, this disclosure also provides an electronic device 400, such as... Figure 4 The diagram shown is a structural schematic of an electronic device 400 provided in an embodiment of this disclosure, including: Processor 41, memory 42, and bus 43; memory 42 is used to store execution instructions, including main memory 421 and external memory 422; the main memory 421, also called internal memory, is used to temporarily store the computational data in processor 41, as well as the data exchanged with external memory 422 such as hard disk. Processor 41 exchanges data with external memory 422 through main memory 421. When the electronic device 400 is running, processor 41 and memory 42 communicate through bus 43, enabling processor 41 to execute... Figure 1 and Figure 2 The steps of a cross-application collaborative pagination query method.

[0090] This disclosure also provides a computer-readable storage medium storing a computer program that, when executed by a processor, performs the steps of the cross-application collaborative paging query method described in the above-described method embodiments. The storage medium may be a volatile or non-volatile computer-readable storage medium.

[0091] This disclosure also provides a computer program product, which includes computer instructions. When the computer instructions are executed by a processor, they can perform the steps of the cross-application collaborative pagination query method described in the above method embodiments. For details, please refer to the above method embodiments, which will not be repeated here.

[0092] The aforementioned computer program product can be implemented through hardware, software, or a combination thereof. In one optional embodiment, the computer program product is specifically embodied in a computer storage medium; in another optional embodiment, the computer program product is specifically embodied in a software product, such as a software development kit (SDK), etc.

[0093] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the specific working process of the device described above can be referred to the corresponding process in the foregoing method embodiments, and will not be repeated here. In the several embodiments provided in this disclosure, it should be understood that the disclosed device and method can be implemented in other ways. The device embodiments described above are merely illustrative. For example, the division of units is only a logical functional division, and in actual implementation, there may be other division methods. Furthermore, multiple units or components may be combined or integrated into another system, or some features may be ignored or not executed. Another point is that the displayed or discussed mutual coupling or direct coupling or communication connection may be through some communication interfaces; the indirect coupling or communication connection of devices or units may be electrical, mechanical, or other forms.

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

[0095] In addition, the functional units in the various embodiments of this disclosure can be integrated into one processing unit, or each unit can exist physically separately, or two or more units can be integrated into one unit.

[0096] If the aforementioned functions are implemented as software functional units and sold or used as independent products, they can be stored in a processor-executable, non-volatile, computer-readable storage medium. Based on this understanding, the technical solution of this disclosure, in essence, or the part that contributes to the prior art, or a portion of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods described in the various embodiments of this disclosure. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0097] Finally, it should be noted that the above-described embodiments are merely specific implementations of this disclosure, used to illustrate the technical solutions of this disclosure, and not to limit it. The protection scope of this disclosure is not limited thereto. Although this disclosure has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that any person skilled in the art can still modify or easily conceive of changes to the technical solutions described in the foregoing embodiments, or make equivalent substitutions for some of the technical features, within the scope of the technology disclosed in this disclosure. Such modifications, changes, or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of this disclosure, and should all be covered within the protection scope of this disclosure. Therefore, the protection scope of this disclosure should be determined by the protection scope of the claims.

Claims

1. A cross-application collaborative pagination query method, characterized in that, The method, applied to the main business subsystem in a pagination query component that includes at least one main business subsystem and one secondary business subsystem, comprises: In response to the pagination query request from the front-end system, the system queries the first query data that meets the query conditions in the local data source, and then calls the business subsystem to query the second query data that meets the query conditions in the corresponding data source. The total amount of data retrieved is counted, and the total number of pages is determined based on the total amount of data and the number of records displayed per page carried in the pagination query request. Pagination operation is then performed on the first query data based on the number of records displayed per page. During the pagination operation, if the page number passed by the current front-end system falls on the first last page of the number of pages corresponding to the first query data, and the amount of data on the first last page is less than the number of records displayed per page, then the first query data on the first last page is temporarily discarded, and the business subsystem is called to perform the pagination operation on the second query data and return the data pagination result to the front-end system for display. When processing the pagination from the business subsystem to the second last page corresponding to the number of pages that can be paginated for the second query data, if the amount of data on the second last page is less than the number of records displayed per page, the amount of page difference data for the second last page is determined based on the number of records displayed per page. Based on the relationship between the amount of page difference data and the amount of data on the first last page, the amount of data that needs to be supplemented on the first last page is determined. The first query data with the amount of data that needs to be supplemented is then merged with the second query data on the second last page and returned to the front-end system for display.

2. The method according to claim 1, characterized in that, Based on the relationship between the page difference data volume and the data volume of the first last page, the amount of data to be supplemented on the first last page is determined. The first query data of the supplemented data volume is then merged with the second query data of the second last page and returned to the front-end system for display. Specifically, this includes: When the amount of data on the first last page is greater than the amount of data in the page difference, the difference between the number of records displayed per page and the amount of data in the page difference is determined to be the amount of data to be supplemented. The first query data corresponding to the amount of data to be supplemented is extracted from the first last page and merged with the second query data in the second last page and returned to the front-end system for display. When the amount of data on the first last page is less than the amount of data in the page difference, the amount of data on the first last page is taken as the amount of data to be supplemented, and the first query data in the first last page and the second query data in the second last page are merged and returned to the front-end system for display.

3. The method according to claim 1, characterized in that, After merging the first query data requiring supplementary data with the second query data from the second last page and returning it to the front-end system for display, the method further includes: When the sum of the data volume of the first last page and the data volume of the second last page is greater than the number of records displayed per page, the page number requested by the front-end system corresponds to the second to last page of the total number of pages. When the front-end system requests to display the last page of the total number of pages, the data volume of the second last page is deducted from the first query data in the first last page, and the result is returned to the front-end system as the last page of the total number of pages.

4. The method according to claim 1, characterized in that, The method further includes: When the amount of data on the first last page is less than the number of records displayed per page, the difference in the amount of data between the amount of data on the first last page and the number of records displayed per page is determined. The starting and ending positions of the second query data that needs to be queried in the business subsystem are determined based on the data volume difference. The starting position and the ending position are sent as query parameters to the slave business subsystem, and the second query data returned by the slave business subsystem from the local data source according to the query parameters is received. The first query data on the first last page is merged with the second query data returned by the business subsystem from the local data source according to the query parameters, and then returned to the front-end system for display.

5. The method according to claim 1, characterized in that, After calculating the total amount of data retrieved and determining the total number of pages based on the total amount of data and the number of records displayed per page carried in the pagination query request, the method further includes: If the first query data does not exist but the second query data does exist, then the business subsystem is directly invoked to perform pagination on the second query data and then returned to the front-end system for display. If the second query data does not exist but the first query data does exist, then the pagination operation is performed directly on the first query data and the system is returned to display the data.

6. The method according to claim 1, characterized in that: During the pagination operation performed by the business subsystem on the second query data, if the amount of data on the second last page meets the number of records displayed per page, the second query data on the second last page is directly returned to the front-end system as the second to last page of the total number of pages for display. The prime number query data of the first last page is returned to the front-end system as the last page of the total number of pages for display.

7. The method according to claim 1, characterized in that, During the pagination operation on the first query data: If the page number passed to the front-end system does not fall on the first last page of the pageable number of the first query data, then the first query data for that page will be directly returned to the front-end system for display.

8. A cross-application collaborative pagination query device, characterized in that, The apparatus, applied to a pagination query component comprising at least one main business subsystem and one secondary business subsystem, includes: The query triggering module is used to respond to the pagination query request of the front-end system, query the first query data that meets the query conditions in the local data source, and call the business subsystem to query the second query data that meets the query conditions in the corresponding data source. The first pagination module is used to count the total amount of data retrieved, determine the total number of pages based on the total amount of data and the number of records displayed per page carried in the pagination query request, and perform pagination operation on the first query data based on the number of records displayed per page. The second pagination module is used to temporarily discard the first query data on the first last page of the first query data if, during the pagination operation, the page number passed by the current front-end system falls on the first last page of the number of pages that can be paginated for the first query data, and the amount of data on the first last page is less than the number of records to be displayed per page. Then, the module calls the business subsystem to perform the pagination operation on the second query data and returns the data pagination result to the front-end system for display. The last page supplementation module is used to determine the page difference data amount of the second last page when the pagination process from the business subsystem reaches the second last page corresponding to the number of pages that can be paginated for the second query data. If the data amount of the second last page is less than the number of records displayed per page, the module determines the page difference data amount of the second last page based on the number of records displayed per page. Based on the relationship between the page difference data amount and the data amount of the first last page, the module determines the amount of supplementary data needed for the first last page. The module then merges the first query data with the second query data of the second last page and returns it to the front-end system for display.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus, wherein the memory stores machine-readable instructions executable by the processor, and when the electronic device is running, the processor communicates with the memory via the bus, and the machine-readable instructions, when executed by the processor, perform the steps of the cross-application collaborative paging query method as described in any one of claims 1 to 7.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the cross-application collaborative paging query method as described in any one of claims 1 to 7.

Images