Report migration method, electronic equipment and storage medium

Abstract

The invention discloses a report migration method, electronic equipment and a storage medium, and belongs to the technical field of information management. Comprising the steps of splitting business logic of a target report based on a first development tool into data processing logic and chart display logic; according to the data processing logic, creating a corresponding data processing storage process in a database, and configuring an intermediate result table associated with the target report; calling a data processing storage process, processing source data of the target report to obtain a data processing result, and writing the data processing result into an intermediate result table; in the second development tool, creating a corresponding visual chart according to the chart display logic, and pointing a data source of the visual chart to the intermediate result table; and acquiring data from the associated intermediate result table through the second development tool, and driving the visual chart to display. According to the method, a set of standardized migration process is constructed, and the threshold and cost of migration from a closed report system to a basic platform are reduced.

Description

Technical Field

[0001] This invention belongs to the field of information management technology, specifically relating to a report migration method, electronic device, and storage medium. Background Technology

[0002] In the field of information system construction, reporting modules built using specific business reporting development tools have long served as crucial data display and business analysis tools. These tools typically offer visual design interfaces, allowing developers to configure report layouts and data sources. Data acquisition relies on writing specific query scripts or calling functions and stored procedures in the database. Over long-term application, these systems have accumulated a vast number of report objects with complex business logic, forming assets heavily reliant on the original development technology stack.

[0003] However, the aforementioned technical approach deeply binds the report implementation logic to a specific underlying database and application server environment, resulting in a high degree of coupling between its data processing core and the front-end presentation layer. This architectural closedness makes it difficult to separate the report module from the existing technology ecosystem. Because the report generation logic and data processing functions are deeply integrated with the specific basic software environment, the entire reporting system lacks portability. When faced with the need to replace the basic hardware and software environment, it is impossible to migrate existing reporting assets to a new, self-controllable platform through a smooth transition. Summary of the Invention

[0004] The purpose of this invention is to provide a report migration method, electronic device, and storage medium that can solve the problems existing in the background art.

[0005] To solve the above-mentioned technical problems, the present invention is implemented as follows: In a first aspect, embodiments of the present invention provide a report migration method, including: The business logic of the target report based on the first development tool is broken down into data processing logic and chart display logic; Based on the data processing logic, a corresponding data processing stored procedure is created in the database, and an intermediate result table associated with the target report is configured. Based on the pre-configured report attribute table and parameter configuration table, the data processing stored procedure is invoked to process the source data of the target report, obtain the data processing result, and write the data processing result into the intermediate result table; wherein, the report attribute table includes at least a data processing enable flag and a data processing stored procedure name, and the parameter configuration table includes at least a parameter order; In the second development tool, a corresponding visualization chart is created according to the chart display logic, and the data source of the visualization chart is pointed to the intermediate result table; The second development tool retrieves data from the associated intermediate result table and drives the visualization chart to display the data, thus completing the report migration.

[0006] Optionally, based on the pre-configured report attribute table and parameter configuration table, the data processing stored procedure is invoked to process the source data of the target report, obtain the data processing result, and write the data processing result into the intermediate result table, including: Based on the data processing enable flag in the report attribute table, determine whether data processing is required for the target report. When data processing is required on the target report, the order of calling parameters for the data processing stored procedure is determined according to the parameter order in the parameter configuration table. The parameters are passed in the order of the calling parameters, and the data processing stored procedure is called to process the source data of the target report. Receive the data processing result returned by the data processing storage procedure, and write the data processing result into the intermediate result table.

[0007] Optionally, the data processing result includes the processing status and the corresponding visualization chart access address. In the second development tool, a corresponding visualization chart is created according to the chart display logic, and the data source of the visualization chart is associated with the intermediate result table, including: Based on the access address of the visualization chart contained in the data processing result, a corresponding visualization chart is created in the second development tool, and the data source of the visualization chart is configured to be associated with the intermediate result table; Based on the parameter configuration table, a mapping relationship is established from the parameters of the target report to the parameters of the visualization chart; wherein, the visualization chart is configured to pass parameters according to the mapping relationship and obtain corresponding data from the associated intermediate result table for display.

[0008] Optionally, data is retrieved from the associated intermediate result table using the second development tool, and the visualization chart is then displayed, including: In response to a chart display request initiated by a user through the second development tool, the chart display request carrying a user identifier and report parameters; Using the second development tool, a pre-configured session association table is queried based on the user identifier to determine the session identifier associated with the user identifier; Using the second development tool, a data query request for the intermediate result table is generated based on the session identifier and the user identifier; When the second development tool uses a public access account to execute the data query request, the data access permissions of the public access account are replaced with the user permissions corresponding to the user identifier through the database and according to the session association table; Using the database and based on the replaced user permissions, the data query request is executed to obtain a dataset that matches the user identifier and the report parameters from the intermediate result table associated with the visualization chart; The second development tool is used to provide the dataset to the visualization chart for rendering and display.

[0009] Optionally, based on a pre-configured session association table, the data access permissions of the public access account are replaced with the user permissions corresponding to the user identifier, including: Query the session association table to determine whether the public access account has an associated session identifier; If the public access account has an associated session identifier, data filtering conditions are generated based on the user identifier; The data filtering conditions are appended to the data query request so that the public access account can only access data within the scope of the user's permissions.

[0010] Optionally, based on the session identifier and the user identifier, a data query request for the intermediate result table is generated, including: Obtain the encrypted environment identifier and encrypted user account carried in the chart display request; The first global parsing function preset in the second development tool is called to decrypt the encrypted environment identifier and obtain the database environment address corresponding to the target report; The second global parsing function pre-built in the second development tool is called to decrypt the encrypted user account and obtain the user identifier; The data query request is generated based on the session identifier, the database environment address, and the user identifier.

[0011] Optionally, after writing the data processing result into the intermediate result table, the method further includes: In response to the data processing result, corresponding log information is created through the database and a corresponding log ID is generated; The log information is associated with the data processing results through the database and written into a pre-created report log record table. The log record table is used to record the log information generated during the generation of each report. The log information includes log ID, report identifier, user identifier, report parameters, data processing status, log viewing period, and visualization chart access address. It also includes: in response to a user's request to view historical reports through the second development tool, retrieving and displaying the corresponding log information based on the log ID recorded in the report log record table.

[0012] Optionally, it also includes: Configure a scheduled cleanup task in the database. The scheduled cleanup task is used to periodically remove invalid data processing results from the intermediate result table. The invalid data includes at least one of the following: data processing results without associated log IDs, data processing results with a report processing status of failure, and data processing results whose log viewing period has expired. The database is used to clean up invalid data processing results in the intermediate result table according to the scheduled cleanup task, and the status of the corresponding data processing result in the report log record table is updated to unviewable.

[0013] In a second aspect, embodiments of this disclosure provide an electronic device, including: a processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of a report migration method.

[0014] Thirdly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the steps of a report migration method.

[0015] The technical solutions provided by the embodiments of the present invention bring at least the following beneficial effects: This invention constructs a standardized, low-intrusion migration process by decomposing the target report's business logic into an architecture that separates data processing from chart display. It performs core data processing in the database using a configuration-based approach, utilizes intermediate result tables for data transfer, and finally provides visualization through basic tools. This reduces the technical barriers and implementation costs of migrating from a closed reporting system to a basic platform. By encapsulating complex business logic in database stored procedures and reusing existing configurations, it not only ensures consistency and data accuracy before and after migration but also achieves a seamless transition in user experience. Furthermore, the modular design of this invention effectively decouples data processing from front-end display, improving system maintainability and scalability, and providing technical support for the rapid and reliable migration of large-scale reporting systems. Attached Figure Description

[0016] Figure 1 This is a schematic diagram illustrating the steps of a report migration method provided in one embodiment of the present invention; Figure 2 This is a schematic diagram of the overall report migration process in one embodiment of the present invention; Figure 3 This is a schematic diagram of the data processing stored procedure call flow in one embodiment of the present invention; Figure 4 This is a schematic diagram of the data query and display process in one embodiment of the present invention. Detailed Implementation

[0017] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of the present invention. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0018] The terms "first," "second," etc., used in the specification and claims of this invention are used to distinguish similar objects and are not used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that embodiments of the invention can be implemented in orders other than those illustrated or described herein. Furthermore, in the specification and claims, "and / or" indicates at least one of the connected objects, and the character " / " generally indicates that the preceding and following objects are in an "or" relationship.

[0019] The following description, in conjunction with the accompanying drawings, details a report migration method, electronic device, and storage medium provided by the present invention through specific embodiments and application scenarios.

[0020] The report migration method proposed in this invention can be specifically implemented in a migration system that includes a first development tool, a database, and a second development tool. During the migration process, the first development tool (i.e., the original Oracle Reports Developer and its runtime environment) serves as the source of the legacy system being migrated. The business logic and configuration of the target report developed based on the first development tool are parsed and extracted. The database (i.e., the database used after migration) acts as the backend for data processing, logic execution, and persistent storage, specifically responsible for carrying the data processing storage process reconstructed according to the original logic, storing intermediate result tables, managing report configuration metadata, executing permission policies, and recording operation logs. The second development tool (which can be a basic BI tool) acts as the frontend for visualization and user interaction, responsible for reconstructing the visualization charts according to the extracted chart display logic, obtaining data from the intermediate result tables or business tables of the database through the configured dataset, and finally completing the rendering and display of the charts, providing an interactive interface to the user.

[0021] Figure 1 This is a schematic diagram illustrating the steps of a report migration method according to an embodiment of the present invention. Please refer to [link / reference]. Figure 1 ,include: Step S11: The business logic of the target report based on the first development tool is broken down into data processing logic and chart display logic.

[0022] Figure 2 This is a schematic diagram of the overall report migration process in one embodiment of the present invention. Please refer to [link / reference]. Figure 2 The overall business logic of the target report developed using the first development tool is structurally analyzed and functionally separated. The aim is to divide the originally tightly coupled and integrated reporting program into two relatively independent logical layers according to its inherent technical responsibilities and business functions: data processing logic focusing on data preparation and processing, and chart display logic focusing on information presentation and interaction.

[0023] Specifically, the first step is to analyze the source code, configuration items, and runtime behavior of the target report to identify each component of the report: including but not limited to the data query statements (such as SQL scripts) that trigger report generation, various business rules and processing functions used for data filtering, calculation, summarization, and transformation, the layout format and chart definitions that determine the final output style, and the parameters and session mechanisms that manage user input and access control. During the analysis, it is necessary to identify which code segments and configurations are purely for retrieving and processing data from the data source, and which are specifically used to control how the data is rendered on the screen in the form of graphics, tables, etc., and interacts with the user. For example, a complex SQL query for calculating annual cumulative sales and its related data cleaning code are essentially data processing logic; while the configuration instruction specifying that the cumulative value should be displayed as a bar chart with specific colors and labels belongs to chart display logic.

[0024] The decomposition is a logical restructuring based on the principle of functional decoupling. For data processing logic, the process of decomposition involves extracting all operations related to data access, business calculation, state updates, and persistent storage, and planning to repackage them into modules that can run independently in the backend database environment, such as stored procedures, functions, or specific data service interfaces.

[0025] For the chart display logic, the process involves extracting all definitions related to visual presentation and user interaction flows. This includes the overall layout structure of the report, the type and position settings of each chart component (such as pie charts, line charts, and tables), the specifications for static and dynamic styles (such as fonts, colors, and sizes), and the behavioral response logic triggered by user interface operations (such as clicking drill-down and parameter input). This part of the logic will be reinterpreted and mapped to adapt to the component model, attribute configuration syntax, and event-driven mechanism of the new reporting tool.

[0026] For those intertwined and complex logical segments in the target report that are difficult to categorize simply (e.g., a script that dynamically generates query conditions based on real-time user input and immediately refreshes the chart display), they can be broken down into a pure data processing unit that receives parameters and generates query conditions, and a pure display and interaction unit that receives new data and refreshes the interface. The two are connected through call relationships and data interfaces.

[0027] Step S12: Based on the data processing logic, create a corresponding data processing stored procedure in the database and configure an intermediate result table associated with the target report.

[0028] Please see Figure 2First, based on the stripped and reconstructed data processing logic, a corresponding data processing stored procedure is created in the database. This stored procedure receives call requests and parameters from the application, executes all business logic related to data preparation, cleaning, calculation, transformation, and persistence in the target report, and standardizes and encapsulates the processing status and results. The creation process involves adapting and converting code that originally relied on the syntax and functions specific to the first development tool (such as specific PL / SQL packages, analytical functions, etc.) one by one into a form conforming to the database's SQL specifications, ensuring the integrity and equivalence of the business logic. The data processing stored procedure defines input parameter interfaces, which should correspond one-to-one with the user query conditions of the target report (such as start and end dates, department codes, project identifiers, etc.). Within the data processing stored procedure, complex data validation, multi-table join queries, aggregation calculations (such as summation, averaging, counting, grouping), logical judgments and branching based on business rules (using CASE WHEN or IF-ELSE structures), and possible data update operations are implemented according to the business sequence.

[0029] Secondly, to support the data acquisition needs of the chart display layer, especially when the data processing logic is complex, computationally time-consuming, or the results need to be persisted for historical queries, this invention creates and configures intermediate result tables associated with the target report. The intermediate result tables serve as a data buffer and storage medium between the data processing storage procedure and the front-end chart display. It is recommended that all intermediate result tables be centrally stored in a separate, dedicated database tablespace for unified storage monitoring, backup, and management.

[0030] Step S13: Based on the pre-configured report attribute table and parameter configuration table, call the data processing stored procedure to process the source data of the target report, obtain the data processing result, and write the data processing result into the intermediate result table; wherein, the report attribute table includes at least a data processing enable flag and a data processing stored procedure name, and the parameter configuration table includes at least a parameter order.

[0031] Please see Figure 2 The system queries pre-configured report attribute tables and parameter configuration tables to determine processing requirements, organizes parameters in an orderly manner, and calls the corresponding data processing stored procedures. Finally, the standardized data processing results are written to a designated intermediate result table, providing a structured data source for subsequent chart displays. The report attribute table includes at least a "Data Processing Enabled" field indicating whether the current report requires backend data processing, and a "Data Processing Stored Procedure Name" field pointing to the specific data processing stored procedure. The parameter configuration table includes at least a "Parameter Order" field to ensure the accurate order of called parameters.

[0032] In an optional implementation, step S13 specifically includes steps S131 to S134: Step S131: Determine whether data processing needs to be performed on the target report based on the data processing enable flag in the report attribute table.

[0033] Figure 3 This is a schematic diagram of the data processing stored procedure call flow in one embodiment of the present invention. Please refer to [link / reference]. Figure 3 When the application receives a request to generate a target report, it first queries the report attribute table based on the unique identifier of the target report (such as the report number). In the retrieved records, it locates and reads the value of the "Data Processing Flag Enabled" field. This field can exist as a Boolean value or a specific character code (such as '1' / 'Y' representing enabled, '0' / 'N' representing disabled). If the read flag value indicates "Enabled" or "Yes," it is determined that the target report needs to execute subsequent data processing logic. If the flag value indicates "Disabled" or "No," it is determined that the target report does not need to execute a dedicated data processing stage; in this case, subsequent data processing calls are skipped, and other data acquisition methods (such as directly querying the business table) are used to provide data for chart display, or the chart display process is directly initiated.

[0034] Step S132: When data processing is required on the target report, the order of calling parameters for the data processing stored procedure is determined according to the parameter order in the parameter configuration table.

[0035] Because the target report may contain multiple query parameters (such as start date, end date, department code, etc.) input by the user or preset by the system, and these parameters must be passed in the order of the parameter list defined in the backend stored procedure to ensure successful invocation, the parameter configuration table associated with the target report is queried. In the parameter configuration table, each parameter record contains basic information such as parameter name, parameter value, and parameter type, as well as a parameter order field (e.g., PROCESS_SEQ). The parameter order value specifies the position of the parameter when the data processing stored procedure is invoked.

[0036] During execution, the "data processing stored procedure name" corresponding to the current report is first retrieved from the report attribute table. Then, based on the target report identifier, all relevant parameter records are filtered from the parameter configuration table. Next, these records are sorted in ascending order according to the value of the parameter order field, thus forming an ordered parameter list. Regardless of how the parameters are stored in the configuration table, they can be accurately sorted during invocation, perfectly matching the interface definition of the backend stored procedure. In this way, parameters in the front-end user interface or application logic are transformed into a parameter array or list with a defined order that can be correctly invoked by the database engine.

[0037] Step S133: Pass the parameters in the order of the calling parameters and call the data processing stored procedure to process the source data of the target report.

[0038] Given a predetermined list of ordered parameters, the application or middleware layer initiates a call to the specified data processing stored procedure via a database connection. During the call, the parameter values ​​from the ordered parameter list are bound sequentially to the respective input parameters of the data processing stored procedure in a predetermined order. Subsequently, the command to call the data processing stored procedure is executed.

[0039] The data processing stored procedure is activated and runs on the database server. Internally, it encapsulates all the decomposed and reconstructed data processing logic, and can perform operations including but not limited to: dynamically constructing and executing complex SQL queries based on input parameter values ​​to extract required data from the source business database; calling other auxiliary functions or procedures for data cleaning, transformation, aggregation, and deep computation; implementing specific business rule validation and data logic processing; and, according to business needs, temporarily storing the final result data prepared for chart display in database memory or a temporary structure. The entire execution process is managed by the database, ensuring the atomicity, consistency, isolation, and durability of data operations. After the call is complete, the stored procedure will prepare the return result according to a predefined encapsulation format (e.g., a composite structure containing execution status codes, result datasets, or message text).

[0040] Step S134: Receive the data processing result returned by the data processing storage procedure and write the data processing result into the intermediate result table.

[0041] After the data processing stored procedure completes execution, the application or calling program receives its output. First, it parses the status identifier (such as the STATUS field) in the returned result to confirm whether the data processing was successful. If the status indicates success, the core data processing result set is extracted from the returned result.

[0042] Subsequently, these data processing results are written to an intermediate result table that has been pre-created or specified for the current target report. The writing operation may include inserting each record in the result set into the intermediate result table one by one, according to the field definitions of the intermediate result table. Ultimately, the data written to the intermediate result table has a structure adapted to the dataset requirements of the second development tool, thus achieving data supply between backend data processing and frontend chart display.

[0043] Step S14: In the second development tool, a corresponding visualization chart is created according to the chart display logic, and the data source of the visualization chart is pointed to the intermediate result table.

[0044] Please see Figure 2 In the second development tool, based on the extracted chart display logic, components for visual charts that users can directly access and manipulate are constructed, and the data consumption source for these visual charts is established on the intermediate result table generated in the preceding steps. Through this step, the normalized data is presented to the end user in an intuitive and interactive graphical manner, thus completing the functional delivery of the report from the first development tool environment to the second development tool.

[0045] In an optional implementation, step S14 specifically includes steps S141 to S142: Step S141: Based on the access address of the visualization chart contained in the data processing result, create a corresponding visualization chart in the second development tool, and configure the data source of the visualization chart to be associated with the intermediate result table.

[0046] The data processing stored procedure encapsulates the visualization chart access address in the data processing result (e.g., the BI_PATH field value stored in the report attribute table, or the BI chart URL returned in the processing result). The visualization chart access address is a unique identifier pointing to a developed or deployed report / chart resource within the second development tool. It can be a complete HTTP / HTTPS link containing the server address, project identifier, report ID, and page parameters, or a resource path that can be resolved within the BI tool.

[0047] First, the application or integration framework locates, loads, or creates the corresponding visual chart object in the second development tool based on the access address of the visual chart. This is essentially a process of following the chart to ensure that the chart template displayed on the front end and the backend processing logic are paired to serve the same business goal. The loaded chart template includes predefined chart types (such as bar charts, line charts, pie charts, tables, etc.), style themes, layout structures, and preliminary data binding rules.

[0048] In the dataset management interface of the second development tool or through configuration scripts, create or modify the underlying dataset for the currently loaded visualization chart. The dataset is configured to point to a specific intermediate result table that stores the data for this (or this type of) report. Configuration operations include: specifying a database connection (which points to the database storing the intermediate result table) and writing a data query statement (which can be SELECT * FROM [intermediate result table name] WHERE LOG_ID = :current log ID or a similar parameterized query) to extract data belonging to the target report generation instance. By setting the "table name" or "SQL query" attribute of the data source to point to the intermediate result table, a direct data pipeline from the visualization chart to the structured processing results is established. In addition, configure the mapping relationship between each field in the dataset and the graphical attributes such as series, category axes, and indicator values ​​in the chart. For example, map the "DATE" field in the intermediate result table to the X-axis of the chart and the "SALES_AMOUNT" field to the Y-axis value.

[0049] Step S142: Based on the parameter configuration table, establish a mapping relationship from the parameters of the target report to the parameters of the visualization chart; wherein, the visualization chart is configured to pass parameters according to the mapping relationship and obtain corresponding data from the associated intermediate result table for display.

[0050] Although specific result sets have been generated using parameters and stored in intermediate result tables during the data processing phase, the same or derived parameters often need to be passed to the second-party development tool for data filtering, drill-down, or highlighting on the front end, especially when the chart is based on a broader dataset (or directly queries the intermediate result table but requires dynamic filtering). Therefore, this transmission link is established based on the mapping information stored in the parameter configuration table. Specifically, the parameter fields configured for the target report and related to the second-party development tool in the parameter configuration table are read, such as BI_PARAM_START (single BI parameter name) and BI_PARAM_END (range parameter end name). The values ​​of these fields indicate the parameter names that the front-end BI tool chart expects to receive. The process of establishing the mapping relationship is as follows: using the parameter name of the original target report (or its identifier in the application system) as the "source," and the BI tool parameter names (BI_PARAM_START, etc.) recorded in the parameter configuration table as the "target," a source-target parameter mapping table is created at the application layer or BI tool integration layer.

[0051] When a user enters or selects parameter values ​​in the front-end report parameter interface of the second tool and triggers chart viewing, the application does not directly use these values ​​to query the database. Instead, it performs the following operations: 1) collects all source parameter values ​​provided by the user; 2) converts the source parameter names into corresponding BI tool parameter names according to the pre-established mapping relationship; 3) passes the converted parameter names and values ​​to the loaded visualization chart component in the format specified by the second development tool (e.g., as a URL query string appended to the chart access address, or set via the JavaScript API provided by the BI tool).

[0052] The visualization charts are pre-configured to accept these externally input parameters. In their dataset definitions, relevant query conditions (such as WHERE clauses) reference these parameter names as filtering conditions. Once the parameters are passed in, the visualization chart's dataset engine uses these parameter values ​​to perform a parameterized query on the associated intermediate result table (or a view based on that table), thus extracting only the subset of data matching the current parameter for rendering. For example, if the user inputs start_date=2023-01-01 and the mapped parameter name is P_START, the query for the chart dataset can become: SELECT * FROM intermediate result table WHERE LOG_ID = :LOG_ID AND DATA_DATE>= :P_START. In this way, an end-to-end parameterized process is achieved from user input to backend data processing and then to frontend chart filtering, making the final displayed chart personalized and contextualized.

[0053] Step S15: Obtain data from the associated intermediate result table using the second development tool and drive the visualization chart to display the data, thus completing the report migration.

[0054] Please see Figure 2 In the runtime environment of the second development tool, it responds to user operation requests, extracts information from the intermediate result table of the populated data, and drives the created visualization chart components to complete rendering and display.

[0055] In an optional implementation, step S15 specifically includes steps S151 to S156: Step S151: In response to a chart display request initiated by the user through the second development tool, the chart display request carries a user identifier and report parameters.

[0056] Figure 4 This is a schematic diagram of the data query and display process in one embodiment of the present invention. Please refer to [link / reference]. Figure 4When a user accesses a migrated report through the application system portal or integration page of the second development tool, their interactive operations (such as clicking a report link, clicking the "Query" or "Generate" button in the parameter interface) will be encapsulated as a chart display request. The chart display request is sent to the report server or application middleware hosting the second development tool via HTTP or internal API calls. The chart display request includes two information carriers: first, a user identifier, used to uniquely identify the current operator; and second, report parameters, i.e., the query conditions entered or selected by the user in the front-end interface, such as a specific time range, department code, project number, etc.

[0057] Step S152: Using the second development tool, query the pre-configured session association table based on the user identifier to determine the session identifier associated with the user identifier.

[0058] Upon receiving a chart display request, the second development tool first extracts the user identifier. Then, using the user identifier as a query condition, it accesses a pre-created session association table in the database. This table records the actual user identifier behind each temporary session (session identifier, such as Session ID) generated when the second development tool connects to the database using a public access account. By querying, it retrieves the most recent valid session record matching the current user identifier, thus resolving the session identifier corresponding to the current user in the database connection. In this way, an anonymous, shared technical session is bound to a specific, permission-bound business user.

[0059] Step S153: Using the second development tool, a data query request for the intermediate result table is generated based on the session identifier and the user identifier.

[0060] By integrating user requests, identity information, and environment configurations, a targeted data query command is generated that can be correctly recognized and executed by the database. The second development tool goes beyond simply concatenating parameters into a basic SQL statement; it integrates a comprehensive request construction process encompassing dynamic environment addressing, secure identity resolution, and session association verification. Through this step, the original, encrypted user presentation request is transformed into a structured database query command containing a clear target data source address (database environment address), a verified user identity (user identifier), and a session link for authorization (session identifier).

[0061] In an optional implementation, step S153 specifically includes steps S1531 to S1534: Step S1531: Obtain the encrypted environment identifier and encrypted user account carried in the chart display request.

[0062] Please see Figure 4 When the second development tool receives a chart display request from the front-end integration, it extracts two encrypted parameters from the transmission carrier of the request: an encrypted environment identifier and an encrypted user account. The encrypted environment identifier and encrypted user account are encrypted using a pre-shared key and encryption algorithm and appended to the request by the upstream application system or security gateway when the user initiates the request, for the purpose of protecting sensitive information (preventing the leakage of database connection information and user identity during transmission).

[0063] The encrypted environment identifier is an encrypted code or token, whose plaintext form corresponds to the logical identifier or configuration code of the specific database environment (such as development, test, or production) where the target report data resides. The encrypted user account is an encrypted string, whose plaintext form is the current operator's system login account or unique user identifier.

[0064] Step S1532: Call the first global parsing function preset in the second development tool to decrypt the encrypted environment identifier and obtain the database environment address corresponding to the target report.

[0065] The second development tool calls its internally pre-built and registered first global parsing function, such as the `getAnalysisDataBaseByCode` function. This first global parsing function is a security service routine pre-developed by the migration implementer and deployed in the global context of the second development tool. The calling process is as follows: The encrypted environment identifier is passed as an input parameter to the first global parsing function. Internally, the first global parsing function first decrypts the ciphertext using a key and algorithm matching the encryption end, restoring the plaintext environment identifier code. Then, based on this identifier code, the first global parsing function queries a pre-configured "environment identifier-database address" mapping table stored in the secure storage area or configuration file of the second development tool. Through this query, the first global parsing function obtains the specific database environment address corresponding to the environment identifier. The database environment address includes the database server's network address (IP or domain name), port number, and the target database's service name or instance name. Finally, the first global parsing function outputs this connectable database environment address as the return value.

[0066] Step S1533: Call the second global parsing function preset in the second development tool to decrypt the encrypted user account and obtain the user identifier.

[0067] The second development tool calls its internally built-in second global parsing function, such as the `getAnalysisUserByUserCode` function. The calling process is as follows: The encrypted user account is passed as input to the second global parsing function. The second global parsing function uses a key system and decryption algorithm that are independent of but equally secure as the first global parsing function to decrypt the input ciphertext, successfully restoring the true user identifier (i.e., the user account). This user identifier is the user's unique identity credential within the business system.

[0068] Step S1534: Generate the data query request based on the session identifier, the database environment address, and the user identifier.

[0069] Set the decrypted database environment address as the physical database target to be pointed to by this query request. Determine the name of the intermediate result table to be queried based on the dataset definition associated with the currently displayed visualization chart. Combine the report parameters entered by the user on the front end with these parameter values, conditionally constructing the filtering conditions in the WHERE or HAVING clause of the query statement. Ensure that the query can locate the data batch corresponding to this report generation instance using the condition LOG_ID = 'current log ID'.

[0070] Session identifiers and user identifiers are injected as security metadata into the "context" or "session state" of query requests through specific methods supported by the database driver or query API (such as setting application context, binding variable attributes, or specific annotation directives). Session identifiers and user identifiers are visible to database-side security policy functions (VPDs) and are key inputs that trigger dynamic permission adjudication.

[0071] Finally, the target database connection information, the specific SQL query text (or the call to the stored procedure), and the embedded security context metadata are encapsulated into a complete data query request object that can be received and processed by the database.

[0072] Step S154: When the second development tool executes the data query request using a public access account, the data access permissions of the public access account are replaced with the user permissions corresponding to the user identifier through the database and according to the session association table.

[0073] To address the issue of ensuring users can only access data within their own permission scope in a second development tool environment that uses public access accounts to connect to the database for simplified management and improved performance—that is, to solve the data isolation problem—this invention proposes a method to transparently switch the access permissions of this query session from the public account's permission set to the permission set of the actual user initiating the request by implementing context-based permission adjudication and replacement on the database server side when the second development tool uses a unified public account with high or specific permissions to initiate a data query request to the database. This achieves seamless inheritance and enhancement of enterprise-level data security policies within the second development tool's development environment without modifying the application front-end or altering user operating habits.

[0074] In an optional implementation, step S154 specifically includes steps S1541 to S1543: Step S1541: Query the session association table to determine whether the public access account has an associated session identifier.

[0075] When the database server receives a data query request initiated by the public access account of the second development tool and embedding specific contextual information (such as the user identifier and session identifier from step S153), the pre-deployed and enabled security policy adjudication engine within the database (e.g., a Virtual Private Database Policy Function based on Oracle database, or a similar custom row-level security interceptor) is activated to extract the session identifier carried in the query request context. Subsequently, using the session identifier as the key query condition, the session association table, which was specifically created during the migration preparation phase, is accessed. The session association table stores the dynamic binding relationship between the session identifier generated each time the public account of the second development tool establishes a valid connection and the actual operating user identifier.

[0076] A quick query is performed to confirm two key pieces of information: First, whether the currently input session identifier exists in the session association table, i.e., whether the session is a legitimately established and recorded active session created through the second development tool; second, if it exists, further verification to confirm whether the session record is currently marked as valid. Only query requests established through legitimate means and correctly associated with a real user identity can proceed to the subsequent permission replacement process, preventing security risks such as privilege escalation or unauthorized access.

[0077] Step S1542: If the public access account has an associated session identifier, generate data filtering conditions based on the user identifier.

[0078] If it is confirmed that the current query initiated by the public access account is associated with a valid and bound user session, data filtering conditions are constructed based on the user identifier carried in the query context.

[0079] The process of generating data filtering conditions essentially involves instantiating predefined row-level data security policies associated with the user identifier into one or more predicate logic rules that can be directly applied to SQL queries. These policies include, but are not limited to: departmental data isolation (e.g., users can only view data from their own department), project data permissions (e.g., users can only access projects they are involved in), and role-based data scope (e.g., displaying summary or detailed data at different granularities based on user roles). By querying the system permission table, user attribute table, or a pre-compiled policy rule base, abstract user permissions are transformed into concrete data filtering conditions. These data filtering conditions define the range of data visible to the user on a specific data table.

[0080] Step S1543: The data filtering conditions are appended to the data query request so that the public access account can only access data within the scope of the user's permissions.

[0081] After generating data filtering conditions for the current user identifier, the original query request text is not modified. Instead, the generated conditions are transparently and forcibly appended to the WHERE clause of the original data query request through the security mechanisms provided by the database (such as the APPLY operation of the VPD strategy).

[0082] This process occurs before the query statement is parsed and actually executed by the database optimizer. The original query is logically combined with data filtering conditions to form a final, security-hardened query statement. Subsequently, the database uses the credentials of the public access account to execute this filtered query. Due to the added filtering conditions, although the public account nominally executes the query, the data rows it can actually retrieve and return are limited to the permissions corresponding to the user's identifier. From the end-user's perspective, the data they obtain is entirely based on their own permissions; from the system administration perspective, all queries are still executed through a unified public account, simplifying connection management and permission configuration. This is a typical example of "incremental modification" and "context-aware" security implementation, effective only for query requests initiated through the public account of the second development tool and associated with a valid user session. It has no impact on other database access methods or existing business functions, thus improving security while ensuring system stability and compatibility.

[0083] Step S155: Using the database and based on the replaced user permissions, execute the data query request to obtain the dataset that matches the user identifier and the report parameters from the intermediate result table associated with the visualization chart.

[0084] Because execution permissions have been replaced with those of the actual user, data filtering conditions for any base tables involved in the query process that have row-level security policies (such as VPD) enabled (if the query relates to such tables, or the generation logic of intermediate result tables depends on such tables) will be based on the current user's identity. The database transparently applies all relevant data access security policies according to the replaced user permissions.

[0085] Finally, retrieve and return a dataset from the specified intermediate results table that fully matches the current user's permission view and satisfies the requirements of the query parameters.

[0086] Step S156: Using the second development tool, the dataset is provided to the visualization chart for rendering and display.

[0087] After receiving the dataset from the database, the second development tool passes it to the visualization chart awaiting the data. Based on pre-configured chart type, style, axis mapping, color scheme, and other display logic, the structured dataset is transformed into intuitive graphical elements. For example, data rows are converted into bars in a bar chart, dots and lines in a line chart, sectors in a pie chart, or rows and columns in a table. Ultimately, the visualization chart carrying business information is presented on the user's browser or client interface.

[0088] In one optional implementation, after writing the data processing result into the intermediate result table, the method further includes: Step S21: In response to the data processing result, create corresponding log information and generate a corresponding log ID through the database.

[0089] Once the data processing stored procedure has finished executing and explicitly returned a success status (e.g., STATUS=1), the database first calls a pre-encapsulated function to retrieve the current log ID. This function generates a unique string or numeric sequence, i.e., the "log ID," based on a database sequence, a high-precision timestamp, and a random factor or a universally unique identifier algorithm. Simultaneously with generating the log ID, the necessary metadata for constructing complete "log information" is also initiated. This metadata captures the entire context of this operation from multiple dimensions: the report identifier originates from the report attribute configuration, representing the service objective of this processing; the user identifier is extracted from the application session or security context, recording the operation subject; the report parameters collect and format all query conditions (such as start date, end date, department filter value, etc.) entered by the user in the front-end interface into a standard structure (such as JSON string) to fully reproduce the user's query intent; the data processing status is inherited from the return result of the stored procedure, recorded as "success", "failure" or with a specific error code; the log viewing period is calculated based on the retention policy preset in the attribute configuration table of the report (such as permanent storage, retention for 30 days, etc.) to determine the expiration time of this log entry; finally, the access address for the visualization chart is also obtained from the configuration information or processing results.

[0090] Step S22: Associate the log information with the data processing results through the database and write it into a pre-created report log record table; the log record table is used to record the log information generated during the generation of each report; the log information includes log ID, report identifier, user identifier, report parameters, data processing status, log viewing period, and visualization chart access address.

[0091] After generating a complete log information object containing a unique log ID, perform the following two operations: First, log records are securely stored in a dedicated repository, and a link is established between it and the generated data. The database first performs an insert operation, writing the assembled log information object as a new data row into the report log table designed and created during the system migration preparation phase. The log table serves as a repository for the history of all report operations in the system, storing and retrieving fields such as log ID, report identifier, user identifier, report parameters, data processing status, log viewing period, and visualization chart access address. The write operation ensures that a "snapshot" of each report generation activity is permanently preserved.

[0092] Second, a one-to-many reference relationship is established between the intermediate result table and the report log table using log IDs. This can be implemented in two ways: one is in the application or database trigger logic, where the generated log ID is included as a required field when writing the data processing result to each record in the intermediate result table, ensuring that each result record "carries" the identifier of its respective log; the other is at the database design level, where the log ID is used as a foreign key in the intermediate result table, referencing the primary key of the report log table. This association enables bidirectional data traceability: given a log ID, all corresponding intermediate result data can be quickly located, reproducing the complete output at that time; conversely, given a single intermediate result record, the entire context log at the time of its generation can also be traced.

[0093] Also includes: Step S31: In response to the user's request to view historical reports through the second development tool, retrieve the corresponding log information and display it based on the log ID recorded in the report log record table.

[0094] When a user uses the historical report module provided by the second development tool to request to view a specific historical report (e.g., selecting a record from the historical task list and clicking "View"), the tool first parses the user's request and extracts the log ID of the target historical record. Then, using the log ID as the precise key, it queries the report log table to retrieve the log information record corresponding to the log ID and presents the information: on one hand, it displays the text portion of the log information record, such as the report identifier, generation time, user identifier, detailed report parameters used, and processing status description, making the user's understanding of the historical query clear at a glance. On the other hand, it dynamically generates an interactive chart display area in the interface using the visual chart access address recorded in the log information. When the chart display area is loaded, the second development tool locates the original chart template based on the address and queries the database for the corresponding data snapshot originally stored in the intermediate results table using the associated log ID. After receiving a query containing this log ID, the database extracts all related data from the corresponding intermediate result table. The second development tool then drives the chart engine to re-render using this raw data, ultimately presenting the user with a visualization chart consistent with historical moments.

[0095] This invention enables the ability to generate data once and reproduce it at any time, enhancing the long-term value of the data. This is a feature that makes the migrated system superior to the original system in terms of functionality, manageability, and user experience.

[0096] In one alternative implementation, it further includes: Step S41: Configure a scheduled cleanup task in the database. The scheduled cleanup task is used to periodically remove invalid data processing results from the intermediate result table. The invalid data includes at least one of the following: data processing results without associated log ID, data processing results with a report processing status of failure, and data processing results whose log viewing period has expired.

[0097] By predefined and deployed cleanup tasks that run periodically and automatically in the database background, data processing results that have lost business value or are no longer allowed to be accessed and stored in intermediate result tables are identified and removed. This effectively prevents problems such as wasted database storage space, degraded query performance, and increased management complexity caused by the unlimited accumulation of invalid data. Configuring scheduled cleanup tasks is a structured process involving goal definition, rule formulation, and scheduling settings. First, a new scheduled task is created in the database, logically pointing to a pre-developed scheduled data processing stored procedure. Second, the rules for determining "invalid data" are defined based on business and compliance requirements.

[0098] Specifically, this includes: First, data processing results without associated log IDs, i.e., records where the LOG_ID field in the intermediate results table is empty. Second, data processing results with a report processing status of failure, i.e., records whose data processing status field explicitly indicates "failure" after querying the report log record table by association with LOG_ID. Third, data processing results where the log viewing period for the corresponding log information has expired, i.e., log viewing period field for the log record table after querying the report log record table by association with LOG_ID, where the valid expiration time is earlier than the current system time.

[0099] Step S42: Using the database, the invalid data processing results in the intermediate result table are cleaned up according to the scheduled cleanup task, and the data processing status of the corresponding data processing result in the report log record table is updated to unviewable.

[0100] When the database scheduler reaches the predetermined execution time according to the configuration in step S41, it triggers and executes the scheduled cleanup task. The execution flow of the scheduled cleanup task is a closed loop of identification, cleanup, marking, and recording. First, invalid data is identified and located. The intermediate result table configuration table is queried, which registers the names of all intermediate result tables that need to be included in the cleanup scope. The intermediate result table configuration table is traversed, and for each intermediate result table, a compound query is executed according to the invalid data judgment rules in step S41. For example, by joining the report log record table using LEFT JOIN, records that meet any one of the following conditions are selected: "LOG_ID is empty", "the STATUS corresponding to LOG_ID is failed", or "the JUMP_LIMIT corresponding to LOG_ID has expired", forming the invalid data result set to be cleaned this time. Second, physical cleanup operations are performed.

[0101] For identified invalid data result sets, a deletion operation is performed under database control, permanently removing them from the corresponding intermediate result tables. Furthermore, after the cleanup operation is complete, the status of log records associated with the deleted data in the report log table is updated. Specifically, for all log IDs that have lost corresponding data due to this cleanup, their data processing status or a status field specifically indicating data availability is updated to "unviewable" or "cleared" in the report log table. This ensures that the system's front-end interface or historical query function can clearly prompt the user that "the relevant data no longer exists, and the chart cannot be viewed" when attempting to access these historical reports, rather than returning errors or blank results, thus maintaining the accuracy of the user interface. Finally, the cleanup job is audited. The program writes a summary of the cleanup task execution, including start time, end time, table name processed, number of deleted records, number of updated log IDs, and final execution result (success / failure), as a log record to the scheduled task log table. This provides system administrators with operational audit clues, facilitating future verification of the cleanup task execution history, analysis of data growth trends, or troubleshooting.

[0102] This invention enables automated management of intermediate result data throughout its entire lifecycle, from generation and use to final cleanup, continuously optimizing database performance and resource utilization while fully ensuring business continuity and data traceability.

[0103] This invention also provides an electronic device, including a processor, a memory, and a computer program stored in the memory and capable of running on the processor. When the computer program is executed by the processor, it implements the various processes described above in an embodiment of a report migration method and achieves the same technical effect. To avoid repetition, it will not be described again here.

[0104] This invention also provides a computer-readable storage medium storing a computer program. When executed by a processor, the computer program implements the processes described above in an embodiment of a report migration method, achieving the same technical effects. To avoid repetition, these processes will not be repeated here. The various embodiments in this specification are described in a progressive manner, with each embodiment focusing on its differences from other embodiments. Similar or identical parts between embodiments can be referred to mutually.

[0105] Although preferred embodiments of the present invention have been described, those skilled in the art, upon learning the basic inventive concept, can make other changes and modifications to these embodiments. Therefore, the appended claims are intended to be interpreted as including the preferred embodiments as well as all changes and modifications falling within the scope of the embodiments of the present invention.

[0106] Finally, it should be noted that in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or terminal device that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such a process, method, article, or terminal device. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, method, article, or terminal device that includes said element.

[0107] The embodiments of the present invention have been described above with reference to the accompanying drawings. However, the present invention is not limited to the specific embodiments described above. The specific embodiments described above are merely illustrative and not restrictive. Those skilled in the art can make many other forms under the guidance of the present invention without departing from the spirit and scope of the claims. All of these forms are within the protection scope of the present invention.

Claims

1. A report migration method, characterized in that, include: The business logic of the target report based on the first development tool is broken down into data processing logic and chart display logic; Based on the data processing logic, a corresponding data processing stored procedure is created in the database, and an intermediate result table associated with the target report is configured. Based on the pre-configured report attribute table and parameter configuration table, the data processing stored procedure is invoked to process the source data of the target report, obtain the data processing result, and write the data processing result into the intermediate result table; wherein, the report attribute table includes at least a data processing enable flag and a data processing stored procedure name, and the parameter configuration table includes at least a parameter order; In the second development tool, a corresponding visualization chart is created according to the chart display logic, and the data source of the visualization chart is pointed to the intermediate result table; The second development tool retrieves data from the associated intermediate result table and drives the visualization chart to display the data, thus completing the report migration.

2. The method according to claim 1, characterized in that, Based on the pre-configured report attribute table and parameter configuration table, the data processing stored procedure is invoked to process the source data of the target report, obtain the data processing result, and write the data processing result into the intermediate result table, including: Based on the data processing enable flag in the report attribute table, determine whether data processing is required for the target report. When data processing is required on the target report, the order of calling parameters for the data processing stored procedure is determined according to the parameter order in the parameter configuration table. The parameters are passed in the order of the calling parameters, and the data processing stored procedure is called to process the source data of the target report. Receive the data processing result returned by the data processing storage procedure, and write the data processing result into the intermediate result table.

3. The method according to claim 1 or 2, characterized in that, The data processing results include processing status and corresponding visualization chart access addresses. In the second development tool, corresponding visualization charts are created according to the chart display logic, and the data source of the visualization charts is associated with the intermediate result table, including: Based on the access address of the visualization chart contained in the data processing result, a corresponding visualization chart is created in the second development tool, and the data source of the visualization chart is configured to be associated with the intermediate result table; Based on the parameter configuration table, a mapping relationship is established from the parameters of the target report to the parameters of the visualization chart; wherein, the visualization chart is configured to pass parameters according to the mapping relationship and obtain corresponding data from the associated intermediate result table for display.

4. The method according to claim 1, characterized in that, The second development tool retrieves data from the associated intermediate result table and drives the visualization chart to be displayed, including: In response to a chart display request initiated by a user through the second development tool, the chart display request carrying a user identifier and report parameters; Using the second development tool, a pre-configured session association table is queried based on the user identifier to determine the session identifier associated with the user identifier; Using the second development tool, a data query request for the intermediate result table is generated based on the session identifier and the user identifier; When the second development tool uses a public access account to execute the data query request, the data access permissions of the public access account are replaced with the user permissions corresponding to the user identifier through the database and according to the session association table; Using the database and based on the replaced user permissions, the data query request is executed to obtain a dataset that matches the user identifier and the report parameters from the intermediate result table associated with the visualization chart; The second development tool is used to provide the dataset to the visualization chart for rendering and display.

5. The method according to claim 4, characterized in that, Based on a pre-configured session association table, the data access permissions of the public access account are replaced with the user permissions corresponding to the user identifier, including: Query the session association table to determine whether the public access account has an associated session identifier; If the public access account has an associated session identifier, data filtering conditions are generated based on the user identifier; The data filtering conditions are appended to the data query request so that the public access account can only access data within the scope of the user's permissions.

6. The method according to claim 4, characterized in that, Based on the session identifier and the user identifier, a data query request for the intermediate result table is generated, including: Obtain the encrypted environment identifier and encrypted user account carried in the chart display request; The first global parsing function preset in the second development tool is called to decrypt the encrypted environment identifier and obtain the database environment address corresponding to the target report; The second global parsing function pre-built in the second development tool is called to decrypt the encrypted user account and obtain the user identifier; The data query request is generated based on the session identifier, the database environment address, and the user identifier.

7. The method according to claim 1, characterized in that, After writing the data processing results into the intermediate result table, the process further includes: In response to the data processing result, corresponding log information is created through the database and a corresponding log ID is generated; The log information is associated with the data processing results through the database and written into a pre-created report log record table. The log record table is used to record the log information generated during the generation of each report. The log information includes log ID, report identifier, user identifier, report parameters, data processing status, log viewing period, and visualization chart access address. It also includes: in response to a user's request to view historical reports through the second development tool, retrieving and displaying the corresponding log information based on the log ID recorded in the report log record table.

8. The method according to claim 7, characterized in that, Also includes: Configure a scheduled cleanup task in the database. The scheduled cleanup task is used to periodically remove invalid data processing results from the intermediate result table. The invalid data includes at least one of the following: data processing results without associated log IDs, data processing results with a report processing status of failure, and data processing results whose log viewing period has expired. The database is used to clean up invalid data processing results in the intermediate result table according to the scheduled cleanup task, and the status of the corresponding data processing result in the report log record table is updated to unviewable.

9. An electronic device, characterized in that, include: A processor, a memory, and a computer program stored in the memory and capable of running on the processor, wherein the computer program, when executed by the processor, implements the steps of the method as described in any one of claims 1-8.

10. A computer-readable storage medium, characterized in that, A computer program is stored on the computer-readable storage medium, which, when executed by a processor, implements the steps of the method as described in any one of claims 1-8.

Images