A report distributed computing method based on cloud computing
By using a cloud-based distributed computing method, report calculation tasks are automatically decomposed and remotely allocated, solving the problem of computational efficiency for large-scale financial statements of group enterprises with high data volumes, and realizing efficient parallel processing and exception handling of report calculations.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ZHONGBO INFORMATION TECH RES INST CO LTD
- Filing Date
- 2023-08-31
- Publication Date
- 2026-06-30
Smart Images

Figure CN117217189B_ABST
Abstract
Description
Technical Field
[0001] This invention belongs to the field of big data technology and relates to a cloud computing-based distributed computing method for reports. Background Technology
[0002] As enterprises become increasingly digitalized, they have accumulated vast amounts of data. The types and volume of business data have reached a considerable scale. Simultaneously, enterprises demand more timely reporting, making traditional reporting methods insufficient. For example, a single monthly financial report for a group company involves eight different reports, including a balance sheet, income statement, and revenue statement, totaling nearly 3,000 indicators. Furthermore, group companies often have multiple financial reporting accounts, resulting in a massive amount of data to be calculated.
[0003] Traditional solutions often involve setting up stored procedures for different reports, performing serial calculations, and then uniformly feeding back the results to the front end for rendering and display based on the set indicator codes. Summary of the Invention
[0004] The purpose of this invention is to provide a cloud computing-based distributed report computing method that solves the technical problems of automatically decomposing fixed report data retrieval tasks according to data retrieval formulas and parameters, and automating remote allocation and control of report data retrieval tasks.
[0005] To achieve the above objectives, the present invention adopts the following technical solution:
[0006] A cloud computing-based distributed report computing method includes the following steps:
[0007] Step 1: The user submits a report calculation task through the front-end page, and the front-end page sends the report calculation task to the server; the server inserts the report calculation task into the main table of calculation tasks according to the asynchronous calculation mode.
[0008] Step 2: The server starts a decomposition program to break down report calculation tasks, polling the main table of current calculation tasks for report calculation tasks that are in an undecomposed state.
[0009] The system designs predefined table templates and calculation formulas and load them into the system cache. Based on the table template and calculation formulas, the cached data and parameter configurations in the report calculation task are used to decompose the subtasks. The subtasks are then in an unprocessed state.
[0010] Step 3: The server automatically calls and executes the subtasks using a multi-threaded automatic polling method;
[0011] Step 4: Establish several remote nodes. The remote services started by the remote nodes include program update service, task invocation service, and heartbeat monitoring service.
[0012] The server allocates subtasks to remote nodes based on the polling algorithm and the resources of the remote nodes;
[0013] Step 5: The remote node obtains the subtask object information through deserialization, generates the data retrieval result based on the subtask object information, and returns it to the server. The server generates the KEY_VALUE result.
[0014] Step 6: The server determines whether all subtasks have been completed, and generates corresponding indicator values based on the summarized results after completion;
[0015] Step 7: The server updates the status results of the main table of the calculation task, and then summarizes them to complete the calculation of the report task.
[0016] Preferably, the status of the report calculation task in the main table of the calculation task includes not decomposed, decomposed, decomposed, calculating, calculated, and calculated failed.
[0017] Preferably, in step 2, Excel cell encoding, custom data retrieval formulas, and system formulas are used. Table design and calculation formula design are performed using the four arithmetic operations (addition, subtraction, multiplication, and division). For custom data retrieval formulas, the `com.jstrd.bi.rp.formula.plugin.RPFormulaBase` class needs to be inherited, and dynamic loading of Java classes is supported through the data retrieval plugin JAR package. Specifically, the steps include:
[0018] Step 2-1: Set up the report and indicator areas to obtain the correspondence between the reports and indicators. At the same time, load the calculation formulas in the indicators, summarize and analyze the custom data retrieval formulas involved, and obtain the formulas and corresponding parameters.
[0019] Step 2-2: Decompose the subtasks according to different custom data retrieval formulas and corresponding parameter settings; the task status after subtask decomposition is unprocessed.
[0020] Preferably, when executing step 4, the server initializes and starts multiple data retrieval threads according to the configured parameters. Each thread continuously polls for subtasks in the unprocessed state. After retrieving a task, the subtask's state is set to "in computation" to ensure that it is not polled by other data retrieval threads. The system dynamically adjusts the number of data retrieval threads according to the concurrency of the current task.
[0021] The heartbeat monitoring service is used by the server to dynamically update the running status of remote servers and monitor whether remote nodes are available.
[0022] The task invocation service is used to receive task data retrieval requests sent by the server. The request content includes the data retrieval formula code, year, month, report account, and the corresponding class and data retrieval JAR package file.
[0023] The program update service is used to update the data retrieval JAR files on the server side;
[0024] The server configures different service ports to ensure that there are no conflicts between the heartbeat monitoring service, task invocation service, and program update service.
[0025] Preferably, when executing step 5, after receiving the calculation task, the remote node obtains the subtask object information through deserialization. The task information includes the year, month, formula code, calculation account code, parameters contained in the formula, corresponding JAVA class name, corresponding JAR package name, and calling parameters. The JAVA class corresponding to the JAVA class name inherits the RPFormul aBase basic class provided by the system. The server dynamically loads the specified JAR package file according to the JAVA class name based on the JAVA reflection mechanism to form an object instance, and constructs one or more String[] parameters according to the parameters contained in the formula and the calling parameters, thereby reflecting and calling the calculate(String[]p1,String[]p2,....,String[]pn) method, which returns an Object object. The Object object supports Map and VOList objects.
[0026] In the `calculate(String[]p1,String[]p2,....,String[]pn)` method, based on parameters such as the account set code, year and month, and calling parameters, the corresponding SQL statements or other logic are executed from the corresponding business tables to generate the required data retrieval results;
[0027] The KEY in the MAP object is in the format of "Account Code_Formula Code (Parameter 1, Parameter 2, ..., Parameter n)", where Parameter 1, Parameter 2, ..., Parameter n are VALUEs, and VALUEs are numeric types. After the calculate(String[]p1,String[]p2,....,String[]pn) method is called successfully, the Map or VOList object will be converted into an XML format string.
[0028] Preferably, when performing step 6, after a single subtask call returns, the server parses the returned XML-formatted string, regenerates the corresponding KEY and VALUE, and saves them to the global MAP cache until all subtasks have been executed and returned results, thereby updating the values returned by all subtask calls to the corresponding MAP.
[0029] After all subtasks have been completed, the server updates the main task to the "calculating" state. Based on the main task ID, it retrieves all the metrics included in the calculation report, loops through all the metrics, and calculates the metric value based on the current report user code and the corresponding metric retrieval expression.
[0030] Preferably, when performing step 7, after all indicator tasks have been calculated, the server updates the report calculation task status to the calculation completion status and actively reminds the user through the front-end page that the report calculation task has been completed. The user can view the report data through the front-end page. During the report calculation process, the user can view the report calculation process and status in real time through the front-end page and monitor the data retrieval status of each decomposed subtask, including the data retrieval formula, year, month, status, parameters, and the remote node sent.
[0031] This invention discloses a cloud-based distributed report computing method that solves the technical problems of automatically decomposing fixed report data retrieval tasks based on data retrieval formulas and parameters, and automating remote allocation and control of report data retrieval tasks. It provides users with a quick way to configure report calculation logic through an Excel-like formula approach, reducing the difficulty of report configuration. It supports decomposing report calculation tasks into several sub-tasks based on different formulas and their configured task decomposition parameters, ensuring that data retrieval with the same parameters for the same formula is calculated only once, greatly improving report calculation efficiency. It provides parallel computing functionality for report sub-tasks by defining multiple data retrieval threads and dynamically adjusting the number of threads to achieve parallel report computing. Sub-tasks are sent to remote data retrieval nodes through polling, and task exception handling is supported. Attached Figure Description
[0032] Figure 1 This is a flowchart of the distributed fixed report calculation service implementation method of the present invention;
[0033] Figure 2 This is a logic diagram for the decomposition of report tasks in this invention;
[0034] Figure 3 This is the subtask distributed task invocation architecture of the present invention. Detailed Implementation
[0035] like Figures 1-3 The aforementioned cloud computing-based distributed report computing method includes the following steps:
[0036] Step 1: The user submits a report calculation task through the front-end page, and the front-end page sends the report calculation task to the server. The server inserts the report calculation task into the main calculation task table according to the asynchronous calculation mode. The status of the report calculation task in the main calculation task table includes undecomposed, decomposed, decomposed, calculating, calculated, and calculated failed.
[0037] In this embodiment, users can select one or more reports to be calculated through the front-end page. The calculated report includes the account set, year, and month information. The account set information supports the parent account set and its sub-account sets. The report calculation is performed asynchronously. The server inserts the calculation task into the main calculation task table based on the submitted information. The initial state is undecomposed.
[0038] The initial state is "undecomposed". The main task decomposition program first updates the state to "decomposing". After successful decomposition, the state is updated to "decomposed". Once all subtasks are completed, the task is updated to "computing". After the computation is completed, it is updated to "computing completed". If an exception occurs, the task is updated to "computing failed". In this embodiment, a pop-up prompt can also be actively displayed to the user through the front-end page.
[0039] In this embodiment, the user selects the report account to be calculated, the form to be calculated, the year, and the month through front-end user operation. Multiple report accounts can be calculated at once, and multiple forms can be calculated. Tasks can be assigned based on form sets or multiple forms, with a form set consisting of multiple forms. After the user successfully assigns a task, pending calculation task information is generated.
[0040] Step 2: The server starts a decomposition program to break down report calculation tasks, polling the main table of current calculation tasks for report calculation tasks that are in an undecomposed state.
[0041] The system designs predefined table templates and calculation formulas and load them into the system cache. Based on the table template and calculation formulas, the cached data and parameter configurations in the report calculation task are used to decompose the subtasks. The subtasks are then in an unprocessed state.
[0042] In this embodiment, to accelerate subsequent report calculation efficiency, the server needs to load all report users, forms, metrics, and corresponding data retrieval formulas into the cache when the service starts. This establishes a correspondence between forms and metrics, as well as a correspondence between the formulas and parameters for each metric. This allows for quick lookup of all the data retrieval formulas and parameters involved in a form, and this mapping ensures that each formula and parameter is calculated only once, preventing duplicate calculations and significantly reducing the computational load of the reports.
[0043] In this embodiment, based on the design concept of EXCEL formulas, EXCEL cell encoding, custom data retrieval formulas, and system formulas are used. The table design and calculation formula design are carried out through the four arithmetic operations of addition, subtraction, multiplication, and division. For custom data retrieval formulas, it is necessary to inherit the com.jstrd.bi.rp.formula.plugin.RPFormulaBase class, and the dynamic loading of JAVA classes is supported by calling the data retrieval plugin jar package.
[0044] In this embodiment, the number retrieval formula is defined as:
[0045] First, define a data retrieval formula to obtain a specific type of business data, such as the balance of a financial account. The main fields of the data retrieval formula include: formula identifier, formula name, the corresponding Java class for data retrieval, the specified JAR file plugin, the parameters passed to the formula (multiple parameters are supported), the number of task decompositions for the report user, and the number of parameter task decompositions.
[0046] Formula identifier: Used to define a number retrieval expression in a cell, usually starting with UEDF_;
[0047] Formula Name: A Chinese description of the formula that accurately conveys its meaning;
[0048] Formula definition class: A formula definition is a specific class in the Java language that must inherit from the specified abstract class com.jstrd.bi.rp.formula.plugin.RPFormulaBase and implement the calculate method in the abstract class.
[0049] public Object calculate(String[]p1,String[]
[0050] p2,...String[]pn)throws Exception{
[0051] / / return obj;
[0052] }
[0053] The function can have zero or more parameters, each of which is an array. The length of the array is determined by the parameters of the formula contained in the expression that retrieves data from different cells. The returned parameter Object supports a Map object, which stores the KEY and VALUE values. The KEY value is composed of multiple parameters in the format 'Report User Code_Formula Identifier_P1_P2_P3...._Pn', where P1, P2...Pn are the formula parameters, and VALUE is the value of the corresponding parameter in the current report user's formula.
[0054] The abstract class contains three member attributes: report_user, calculation year, and calculation month. A report_user supports multiple report_users; one or more report_users can be selected at a time to calculate a report. Report_users support hierarchical relationships. The calculation year and calculation month refer to the year and month selected when calculating a specific report.
[0055] Formula parameters: Each formula can have multiple parameters, separated by commas. For example, to retrieve the account balance, you need to enter the specific account code and debit / credit direction. The account code and debit / credit direction are the parameters. Currently, parameters support character types, such as...
[0056] UEDF_KMYE(1001,J), where debit balance is represented by J and credit balance by D.
[0057] The specified JAR file plugin: When the server calls the Java class for the data retrieval formula, it loads the class files from the JAR package in the specified directory. Technical staff first package the class files into a JAR file and upload it to the specified directory using the platform's upload function. The JAR file is not stored in the standard J2EE application's WEB-INF / lib directory on the server side, nor is it placed in the lib directory used for server loading on the remote data retrieval node. This prevents automatic loading during service startup or when files change. Later, if the data retrieval logic is adjusted, it needs to be compiled, packaged into a JAR file, and re-uploaded for updates.
[0058] Report Account Task Decomposition Count: Considering the multiple accounting sets for the group, which may involve batch data retrieval from different accounting sets, the report account task decomposition count is used to split tasks based on the number of report accounts. When the parameter value is 0, it means that the calculation task is not decomposed according to the report account. When the parameter value is not 0, the task will be split according to the report account. For example, when the parameter is 2, if 4 different report accounts are calculated, a single formula will be split into 2 calculation tasks.
[0059] Parameter Task Decomposition Count: The same data retrieval formula may have multiple different parameters in the report definition, such as UEDF_YE(1001) and UEDF_YE(1002). When the parameter is 0, it means that the calculation task is not decomposed based on the number of different parameters. When it is not 0, the task will be decomposed according to the parameter task decomposition count. Thus, when the parameter value is 2, the data retrieval formula A has 4 different parameters, so the data retrieval formula A will be split into 2 calculation sub-tasks.
[0060] Step 2 specifically includes the following steps:
[0061] Step 2-1: Set up the report and indicator areas to obtain the correspondence between reports and indicators. Load the calculation formulas in the indicators and summarize and analyze the custom data retrieval formulas involved to obtain the formulas and their corresponding parameters; for example, UDEF_YE(1001), UDEF_YE(1002) formats. Establish the correspondence between the indicator and the corresponding custom data retrieval formula. This allows you to obtain all custom data retrieval formulas and parameters involved in all indicators under this report, and remove duplicate custom data retrieval formulas and parameters. For example, if different indicators all contain UDEF_YE(1001), it will only be calculated once.
[0062] In an Excel-like report, a specified indicator range is set. Each cell within the indicator range represents an indicator, and a unique indicator code is set based on the row number, column number, and form code of the indicator, in the format [indicator code_row number_column number]. For example, [11_20_30] represents the cell in row 20 and column 30 of the report with form code 11. In each cell, a predefined formula is used with corresponding parameters, arithmetic operations (addition, subtraction, multiplication, and division), and some server-side preset formulas to set the actual data retrieval logic expression for each cell. For example, MA X(UDEF_YE(1001),UDEF_YE(1002)) represents retrieving the larger balance between accounts 1001 and 1002. The server-side preset system functions include two types of formulas: calculation formulas and logical formulas. Calculation formulas include MAX, MIN, AVG, SUM, ABS, etc., and logical formulas include IF, EQUALS, etc.
[0063] Step 2-2: Decompose the subtasks according to different custom data retrieval formulas and their corresponding parameter settings; the task status after subtask decomposition is "unprocessed". For example, the UDEF_YE data retrieval formula has 6 different parameters after deduplication, such as 1001, 1002, 1003, 1004, 1005, and 1006. If the parameter task decomposition number of the UDEF_YE and UDEF_FSE formulas is 3, then UDEF_YE will have two subtasks, TASK1 (1001, 1002, 1003) and TASK2 (1004, 1005, 1006), while UDEF_FSE will have one subtask, TASK3 (1001, 1002). The task status after subtask decomposition is "unprocessed".
[0064] In this embodiment, task decomposition involves retrieving tasks from the task information to be calculated, obtaining the report to be calculated based on the task code, then retrieving all indicators from the report, and finally obtaining the data retrieval formulas and corresponding parameters for each cell based on the indicators. This allows for the rapid acquisition of all data retrieval formulas and their corresponding parameters. The data retrieval formulas are polled to obtain all their parameters. Based on the task decomposition count and parameter task decomposition count set in the formula, the formula is decomposed into one or more tasks. This process decomposes the calculation task according to the data retrieval formulas and parameters.
[0065] Step 3: The server automatically calls and executes the subtasks using a multi-threaded automatic polling method.
[0066] In this embodiment, the server supports automatic execution of the decomposed subtasks. Upon startup, the server initializes and starts multiple data retrieval threads based on configured parameters. Each thread continuously polls for unprocessed subtasks, and after retrieving a task, sets it to "in computation" to ensure it is not polled by other data retrieval threads. The server can dynamically adjust the number of data retrieval threads based on the current task concurrency.
[0067] Step 4: Establish several remote nodes. The remote services started by the remote nodes include program update service, task invocation service, and heartbeat monitoring service.
[0068] When the server starts, it initializes and starts multiple data retrieval threads according to the configured parameters. Each thread continuously polls for subtasks that are in an unprocessed state. After retrieving a task, it sets the state of the subtask to "in computation" to ensure that it is not polled by other data retrieval threads. The server dynamically adjusts the number of data retrieval threads according to the concurrency of the current task.
[0069] This invention defines multiple remote data retrieval service nodes and starts remote services. The remote data retrieval service nodes start three services: heartbeat monitoring service, task invocation service, and data retrieval program update service.
[0070] The heartbeat monitoring service dynamically updates the running status of remote servers on the server side, monitoring the availability of remote nodes. This ensures that tasks are not assigned to unavailable nodes during task distribution, thus guaranteeing a high success rate. The heartbeat service periodically checks the status of remote data retrieval servers and updates their running status to ensure available services are provided during task allocation. If an available remote node cannot be found, local service calls are supported. To ensure timely updates to remote service status, the heartbeat monitoring service can be configured with a polling interval, currently updating once per minute.
[0071] The task invocation service is used to receive task data retrieval requests sent by the server. The request content includes the data retrieval formula code, year, month, report account, and the corresponding class and data retrieval JAR package file.
[0072] The program update service is used to update the data retrieval JAR files on the server side. To ensure the accuracy of the data retrieved by remote data retrieval nodes, the data retrieval program update service automatically synchronizes the local data retrieval logic plugin program on the server to the remote data retrieval nodes, guaranteeing program accuracy.
[0073] The server configures different service ports to ensure that there are no conflicts between the heartbeat monitoring service, task invocation service, and program update service.
[0074] The server assigns subtasks to remote nodes based on the polling algorithm and the resources of the remote nodes.
[0075] In this embodiment, the round-robin algorithm allows data retrieval nodes to define different weights based on the configuration of the remote server. The server can then allocate tasks using the round-robin algorithm based on these weights. The larger the weight value, the more data retrieval tasks are allocated within the same time period.
[0076] In this embodiment, when the data retrieval thread obtains an unprocessed subtask, it will automatically obtain the current optimal remote data retrieval node according to the polling algorithm. The remote data retrieval node will set different weights according to the local resources to ensure that the node with high resources can distribute more tasks.
[0077] The server automatically updates the status of the remote data retrieval node service. The remote data retrieval node provides two services: a task receiving service to receive tasks sent from the server, and a heartbeat registration service to receive heartbeat requests from the server. The server polls the remote data retrieval node, sending heartbeats. If a successful response is received, the server updates the remote data retrieval node's status to "available," making it an allocable data retrieval node during the round-robin task allocation process.
[0078] Step 5: The remote node obtains the subtask object information through deserialization, generates the data retrieval result based on the subtask object information, and returns it to the server. The server generates the KEY_VALUE result.
[0079] After receiving the calculation task, the remote node obtains the subtask object information through deserialization. The task information includes the year, month, formula code, calculation account code, parameters contained in the formula, corresponding JAVA class name, corresponding JAR package name, and calling parameters. The JAVA class corresponding to the JAVA class name inherits the RPFormulaBase base class provided by the server. The server dynamically loads the object instance from the specified JAR package file according to the JAVA class name based on the JAVA reflection mechanism, and constructs one or more String[] parameters according to the parameters contained in the formula and the calling parameters, thereby reflecting and calling the calculate(String[]p1,String[]p2,....,String[]pn) method, which returns an Object object. The Object object supports Map and VOList objects.
[0080] In the `calculate(String[]p1,String[]p2,....,String[]pn)` method, based on parameters such as the account set code, year and month, and calling parameters, the corresponding SQL statements or other logic are executed from the corresponding business tables to generate the required data retrieval results;
[0081] The KEY in the MAP object is in the format of "Account Code_Formula Code (Parameter 1, Parameter 2, ..., Parameter n)", where Parameter 1, Parameter 2, ..., Parameter n are VALUEs, and VALUEs are numeric types. After the calculate(String[]p1,String[]p2,....,String[]pn) method is called successfully, the Map or VOList object will be converted into an XML format string.
[0082] Step 6: The server determines whether all subtasks have been completed, and generates corresponding indicator values based on the summarized results after completion;
[0083] When a single subtask call returns, the server parses the returned XML-formatted string, regenerates the corresponding KEY and VALUE, and saves them to the global MAP cache. This process continues until all subtasks have been executed and returned results, thereby updating the corresponding MAP with the values returned by all subtask calls.
[0084] After all subtasks have been completed, the server updates the main task to the "calculating" state. Based on the main task ID, it retrieves all the metrics included in the calculation report, loops through all the metrics, and calculates the metric value based on the current report user code and the corresponding metric retrieval expression.
[0085] For example, the data retrieval expression for indicator [11_20_30] is UEDF_YE(1001)+UEDF_YE(1002)+UEDF_FSE(1001). The data retrieval formula and parameters contained in the indicator cache are obtained, and the calculated report account code is added to form the KEY value of A3201_UEDF_YE(1001), A3201_UEDF_YE(1002), and A3201_UEDF_FSE(1001). Assuming that 100, 200, and 300 are obtained from the global MAP cache according to the KEY value, these three values are used to replace the formula and parameters in the indicator data retrieval expression, and the final data retrieval expression is "100+200+300". The expression "100+200+300" is compiled and executed by the FEL expression technology engine, and the expression is compiled into bytecode to obtain the expression value of 600. The account set code, year, month, indicator code, and indicator value are recorded. Then, iterate through all metrics of the report task to obtain the metric values, and perform batch updates using the java.sql.PreparedStatement batch insert method.
[0086] Step 7: The server updates the status results of the main table of the calculation task, and then summarizes them to complete the calculation of the report task.
[0087] Once all indicator tasks are calculated, the server updates the report calculation task status to "calculation completed" and proactively notifies the user through the front-end page that the report calculation task has been completed. The user can view the report data through the front-end page. During the report calculation process, the user can view the process and status of the report calculation in real time through the front-end page, and monitor the data retrieval status of each subtask, including the data retrieval formula, year, month, status, parameters, and the remote node to which the data is sent.
[0088] This invention loads the data retrieval formula class from a JAR file in a specified directory, ensuring that an instance object is dynamically generated via ClassLoader each time the system executes. This guarantees that if the data retrieval logic changes, the data retrieval logic class can be updated in real time without restarting the remote data retrieval node service. It also supports any number of data retrieval nodes, ensuring that the data retrieval plugin JAR files in each node can be quickly synchronized to all remote data retrieval nodes. The invention supports updating and uploading JAR file plugins on the server side. When the server detects a change in the JAR file, it calls the data retrieval program update service provided by each remote data retrieval node, synchronizing the JAR file to all remote data retrieval nodes in real time. This achieves synchronous updates and dynamic loading of JAR files, greatly improving system availability. This invention also considers the network stability of remote data retrieval nodes and the reliability of task distribution under abnormal conditions.
[0089] This invention discloses a cloud-based distributed report computing method that solves the technical problems of automatically decomposing fixed report data retrieval tasks based on data retrieval formulas and parameters, and automating the remote allocation and control of report data retrieval tasks. It provides users with a quick way to configure report calculation logic through an Excel-like formula approach, reducing the difficulty of report configuration. It supports decomposing report calculation tasks into several sub-tasks based on different formulas and their configured task decomposition parameters, ensuring that data retrieval with the same parameters for the same formula is calculated only once, greatly improving report calculation efficiency. It provides parallel computing functionality for report sub-tasks by defining multiple data retrieval threads and dynamically adjusting the number of threads. Sub-tasks are sent to remote data retrieval nodes through polling, and task exception handling is supported.
Claims
1. A cloud computing-based distributed report computing method, characterized in that: Includes the following steps: Step 1: The user submits a report calculation task through the front-end page, and the front-end page sends the report calculation task to the server; the server inserts the report calculation task into the main table of calculation tasks according to the asynchronous calculation mode. Step 2: The server starts a decomposition program to break down report calculation tasks, polling the main table of current calculation tasks for report calculation tasks that are in an undecomposed state. The table design and calculation formula are predefined and then loaded into the system cache. Based on the table design and calculation formula, the cache data and parameter configuration in the report calculation task are decomposed into subtasks. The subtasks are then in an unprocessed state. Step 3: The server automatically calls and executes the subtasks using a multi-threaded automatic polling method; Step 4: Establish several remote nodes. The remote services started by the remote nodes include program update service, task invocation service, and heartbeat monitoring service. The server allocates subtasks to remote nodes based on the polling algorithm and the resources of the remote nodes; Step 5: The remote node obtains the subtask object information through deserialization, generates the data retrieval result based on the subtask object information, and returns it to the server. The server generates the KEY_VALUE result. Step 6: The server determines whether all subtasks have been completed, and generates corresponding indicator values based on the summarized results after completion; Step 7: The server updates the status results of the main table of the calculation task, and then summarizes them to complete the calculation of the report task.
2. The distributed report computing method based on cloud computing as described in claim 1, characterized in that: The status of the report calculation tasks in the main table of the calculation tasks includes not decomposed, decomposed, decomposed, calculating, calculated, and calculated failed.
3. The distributed report computing method based on cloud computing as described in claim 1, characterized in that: In step 2, Excel cell encoding, custom data retrieval formulas, and system formulas are used. Table design and calculation formula design are performed using the four arithmetic operations (addition, subtraction, multiplication, and division). For custom data retrieval formulas, the `com.jstrd.bi.rp.formula.plugin.RPFormulaBase` class needs to be inherited, and dynamic loading of Java classes is supported through the data retrieval plugin JAR package. The specific steps include: Step 2-1: Set up the report and indicator areas to obtain the correspondence between the reports and indicators. At the same time, load the calculation formulas in the indicators, summarize and analyze the custom data retrieval formulas involved, and obtain the formulas and corresponding parameters. Step 2-2: Decompose the subtasks according to different custom data retrieval formulas and corresponding parameter settings; the task status after subtask decomposition is unprocessed.
4. The distributed report computing method based on cloud computing as described in claim 1, characterized in that: When executing step 4, the server initializes and starts multiple data retrieval threads according to the configured parameters. Each thread continuously polls for subtasks with an unprocessed status. After retrieving a task, it sets the status of the subtask to "in computation" to ensure that it is not polled by other data retrieval threads. The system dynamically adjusts the number of data retrieval threads based on the current concurrency of the task; The heartbeat monitoring service is used by the server to dynamically update the running status of remote servers and monitor whether remote nodes are available. The task invocation service is used to receive task data retrieval requests sent by the server. The request content includes the data retrieval formula code, year, month, report account, and the corresponding class and data retrieval JAR package file. The program update service is used to update the data retrieval JAR files on the server side; The server configures different service ports to ensure that there are no conflicts between the heartbeat monitoring service, task invocation service, and program update service.
5. The distributed report computing method based on cloud computing as described in claim 2, characterized in that: When executing step 5, after receiving the calculation task, the remote node obtains the subtask object information through deserialization. The task information includes the year, month, formula code, calculation account code, parameters contained in the formula, corresponding JAVA class name, corresponding JAR package name, and calling parameters. The JAVA class corresponding to the JAVA class name inherits the RPFormul aBase basic class provided by the system. The server dynamically loads the specified JAR package file according to the JAVA class name based on the JAVA reflection mechanism to form an object instance. Based on the parameters contained in the formula and the calling parameters, it constructs one or more String[] parameters, thereby reflecting and calling the calculate(String[]p1,String[]p2,....,String[]pn) method, which returns an Object object. The Object object supports Map and VOList objects. In the `calculate(String[]p1,String[]p2,....,String[]pn)` method, based on parameters such as the account set code, year and month, and calling parameters, the corresponding SQL statements or other logic are executed from the corresponding business tables to generate the required data retrieval results; The KEY in the MAP object is in the format of "Account Code_Formula Code (Parameter 1, Parameter 2, ..., Parameter n)", where Parameter 1, Parameter 2, ..., Parameter n are VALUEs, and VALUEs are numeric types. After the calculate(String[]p1,String[]p2,....,String[]pn) method is called successfully, the Map or VOList object will be converted into an XML format string.
6. The distributed report computing method based on cloud computing as described in claim 5, characterized in that: When executing step 6, after a single subtask call returns, the server parses the returned XML-formatted string, regenerates the corresponding KEY and VALUE, and saves them to the global MAP cache until all subtasks have been executed and returned results, thereby updating the values returned by all subtask calls to the corresponding MAP. After all subtasks have been completed, the server updates the main task to the "calculating" state. Based on the main task ID, it retrieves all the metrics included in the calculation report, loops through all the metrics, and calculates the metric value based on the current report user code and the corresponding metric retrieval expression.
7. The cloud computing-based distributed report computing method as described in claim 6, characterized in that: When performing step 7, once all indicator tasks have been calculated, the server updates the report calculation task status to "calculation completed" and proactively notifies the user through the front-end page that the report calculation task has been completed. The user can view the report data through the front-end page. During the report calculation process, the user can view the report calculation process and status in real time through the front-end page, and monitor the data retrieval status of each decomposed subtask, including the data retrieval formula, year, month, status, parameters, and the remote node to which the data is sent.