A method for generating a graphic report based on server-side calls

Abstract

A method for generating graphical report based on server call, 1) based on linux server, the server installs web browser, and installs the system font required by the graphical report rendering on the server. 2) Front-end coding, realize the related function of chart generation, contain page initialization, call server interface to obtain chart required data, use Echarts technology to complete the drawing of chart, after page loading, call Echarts related API to convert chart to file stream and return to server side, and provide link entry for server access. 3) Back-end coding, introduce Selenium related dependencies, and configure the corresponding version of the driver program of the browser installed on the remote server. The server calls the SDK provided by Selenium, communicates with the server browser using the driver program, accesses the link provided in 2), and completes the call to the front-end page. 4) Configure the general template (.docx) required to generate the report.

Description

Technical Field

[0001] This invention relates to the fields of computer processing technology and file processing, and in particular to a method and system for periodically generating graphical reports by a server. Background Technology

[0002] Creating various types of reports has always been a significant part of the daily work of corporate employees. However, for reports with fixed formats and high objectivity, using software programs to automatically generate them is undoubtedly a more efficient solution.

[0003] The reports generated by the aforementioned program generally include narrative text and functional charts. For functional charts, creating aesthetically pleasing and fully functional charts based on existing server-side technologies and their limitations is quite challenging. Therefore, it is necessary to rely on front-end technologies for chart creation.

[0004] While front-end chart creation can perfectly solve the above problems in terms of content, it is difficult to achieve the same timed scheduling effect as the server in terms of process control. This contradicts our original intention of automatically generating reports on a schedule. This leads to the core of this application: how to enable the server to call the front-end page to generate reports and charts on a schedule.

[0005] In existing publicly available technologies, PhantomJS is generally used to implement the above scenarios. PhantomJS is a headless WebKit scripting language with a built-in JavaScript API. It provides fast and native support for various web standards, including DOM manipulation, CSS selectors, JSON, Canvas, and SVG. Simply put, PhantomJS is a programmable headless browser. A headless browser is essentially a browser engine, including a JavaScript parsing engine, rendering engine, and request processing, but not the browser itself that displays and interacts with the user. The typical approach is to include the PhantomJS library in the server-side program, construct the necessary data for the chart within the program, connect to PhantomJS via a command prompt, parse the pre-written JavaScript script with the data, render the page, generate the chart, and then send the chart file back to the server using front-end technology.

[0006] While PhantomJS fulfills the requirement of server-side calls to front-end pages, it has a fatal flaw: PhantomJS was discontinued in 2018. This undoubtedly poses a significant security risk for production projects, and issues arise regarding technical and ecosystem support during later use. Furthermore, the applicant recently discovered compatibility issues between PhantomJS and some mainstream front-end technologies. For example, JavaScript rendered in PhantomJS produces blank images when using html2canvas for screenshots, and the images are not recognized when inserted into Word documents.

[0007] In summary, in order to overcome the shortcomings of existing technologies, a more efficient and reliable method and system for generating graphical reports based on server-side calls is needed. IV. Summary of the Invention

[0008] The purpose of this invention is to overcome the shortcomings of existing technologies and provide a more efficient and reliable method and system for generating graphical reports based on server-side calls.

[0009] To solve the above-mentioned technical problems, the technical solution of the present invention is a method for generating graphical reports based on server-side calls, the specific implementation steps of which are as follows:

[0010] The steps are as follows: Step 1: Based on a Linux server, install a web browser on the server, such as the mainstream ones like Chrome or Firefox, and install the system fonts required for rendering graphical reports on the server.

[0011] Step 2: Front-end (web-side) coding to implement chart generation functions, including calling the server-side interface to obtain the data required for the chart during page initialization, using Echarts technology to draw the chart, and calling the relevant Echarts API to convert the chart into a file stream and send it back to the server after the page is loaded, and providing a link to access the server.

[0012] Step 3: Backend (data and logic processing) coding, including importing Selenium dependencies and configuring the corresponding browser driver installed on the remote server. The server calls the Selenium SDK, uses the driver to communicate with the server browser, creates a server browser access process, and accesses the link provided in Step 2 to complete the call to the frontend page.

[0013] Step 4: Configure the program to generate a general template (.docx) for the report. Using anchor point technology and the open-source technology Poi-tl, insert the chart file returned by the front end in step 3 into the corresponding position in the report, and regenerate a new report (.docx).

[0014] Step 2: Based on the React client framework, code the code and import the Echarts open-source library to implement functions such as rendering graphical reports, monitoring, converting graphical pages to files, and uploading to a file server. The process is as follows:

[0015] 1) Use npm to import the React version of the Echarts open-source library.

[0016] 2) Use the init method provided by Echarts to initialize the graphical report and generate rendering settings.

[0017] 3) Use the rendering completion listener provided by Echarts to monitor the rendering process.

[0018] 4) After rendering is complete, use the getDataURL method provided by Echarts to file the report.

[0019] 5) Call the server's file upload interface to persist the graphical report to the file server.

[0020] Step 3: Based on Java server-side coding, using Selenium WebDriver 3.x, the server application controls the web browser's behavior, actively generating a URL for the graphical report provided in Step 2 in the web browser. This triggers the persistence of the graphical report created in Step 2 to the server-side file server. Simultaneously, it calls a series of SKD methods provided by Selenium to listen for page rendering completion and then disconnects the server application from the web browser. The main flow is as follows:

[0021] 1) Use Maven dependency management and include the Selenium WebDriver 3.x library package in the server-side configuration.

[0022] 2) The server-side uses a Selenium Manager driver that matches the local web browser version.

[0023] 3) `new ChromeDriver(ChromeOptions)` completes the initialization of WebDriver, including loading the driver location and setting web browser access.

[0024] 4) Call the WebDriver.get() SDK method provided by WebDriver to establish communication between the server and the web browser, and automatically trigger the generation and rendering of graphical reports.

[0025] 5) Render the graphical report page. After rendering, file the graphical report and persist it to the server file server.

[0026] 6) WebDriver's `quit` function shuts down communication between the server and the web browser, releasing resources;

[0027] In step 3, to achieve the rational allocation and utilization of server resources and the rapid reversal of the entire server-side call to generate graphical reports, Selenium is used to provide a page DOM probe technology. The server continuously probes the successful DOM nodes agreed upon with the front end in advance. If the probe is successful, it can accurately know that the current page chart file stream has been successfully returned. Then, the communication channel established between the current server and the web browser is closed to achieve the purpose of server resource scheduling and allocation and the reversal of the overall process.

[0028] Specifically, the server and client agree on two specific DOM nodes for the page: the number of graphical reports rendered on the page (imageSize) and the set of results returned by the server's file persistence interface for the graphical reports (uploadDatas). The Selenium WebDriver 3.x component is used to establish communication between the server and the web browser, scheduling and triggering the rendering of the graphical report generation page on the web browser. At this point, the graphical report generation page requests the server's API data interface to obtain the necessary business data for generating the graphical reports. Based on the data structure returned by the server, the number of graphical reports generated on the current page is set (imageSize). If data retrieval fails, imageSize is set to -1. When the echarts myChart.on('finished',function) event listens for the completion of a graphical report rendering, myChart.getDataURL() is called to convert the graphical report into a Base64 file stream. Simultaneously, the server's upload method is called to persist the graphical report data to the server's file server, and the result returned by the upload method is recorded in the uploadDatas collection.

[0029] The server uses the WebDriverWait.until(callBack) SDK method provided by Selenium to detect the values ​​of imageSize and uploadDatas.size() every second. When the imageSize value is found to be -1, it indicates that the rendering of the current graphic report has failed. The WebDriver.quit() SDK method is called to disconnect the communication between the server application and the web browser and to record the failure for subsequent retry. When the detected imageSize and uploadDatas.size() values ​​are equal, it indicates that the rendering of the batch graphic report has been completed. The communication between the server and the web browser is closed and resources are released.

[0030] The scheduling platform is used to activate a task in the report generation service that triggers the front-end page at regular intervals. Specifically, the server includes the relevant Selenium dependencies and configures the driver corresponding to the browser version installed on the remote server. The server calls the SDK provided by the Selenium dependency package to communicate with the browser on the remote server, creating a browser access process. The program automatically inputs the URL provided by the front-end chart generation service, triggering the front-end page to load. The specific implementation is as follows:

[0031] 1) Install the Selenium library and include the WebDriver 3.x component (WebDriver is an API and protocol that defines a language-neutral interface for controlling the behavior of web browsers). In this case, we use Maven to reference the selenium-java jar package dependency to complete the installation.

[0032] 2) Download the driver version corresponding to your local web browser from the official Selenium Manager website, and use System.setProperty("webdriver.chrome.driver",driverFile) to load the local driver;

[0033] 3) Use ChromeOptions to obtain the necessary parameters for controlling the behavior of the web browser in WebDriver, and use newChromeDriver(ChromeOptions) to initialize WebDriver;

[0034] 4) Call the WebDriver.get() SDK method provided by WebDriver to create a server application that communicates with the web browser, create a browser access process, control the web browser to automatically input the URL for generating the graphical report provided in step 2, and thus trigger the graphical report rendering process created in step 2.

[0035] 5) The graphical report page uses echarts to render the graphical report and listens for the rendering completion event. After rendering is complete, the report is fileified and the server upload file interface is called to persist the final generated graphical report to the server file server.

[0036] 6) Call the WebDriverWait and WebDriverWait.until(callBack) SDK methods provided by WebDriver to periodically detect the page DOM structure provided in step 2, and attempt to obtain the specific DOM nodes required by the server and client to complete page rendering as agreed. If detected, it means that the current page has been successfully rendered. Call the WebDriver.quit() SDK method to disconnect the communication between the server application and the web browser, thus completing this task of actively triggering the client network connection.

[0037] Beneficial effects and significant advantages compared to existing technologies:

[0038] (1) This invention utilizes the web automation tool Selenium to achieve direct communication between the server and the browser, allowing the front-end code to run directly on the real browser, instead of using PhantomJS to simulate browser behavior as in the existing method. The advantages of using Selenium to schedule the front-end page are as follows: it can completely avoid compatibility issues caused by the real browser and the headless browser simulated by PhantomJS; and because it greatly simulates the user's final display, it also optimizes the user experience to a certain extent.

[0039] (2) Traditionally, when using PhantomJS to simulate browser behavior and request a specified URL, we can only perceive whether the request was successful and the page loading status from the HTTP response. However, this is inaccurate. For example, in the requirement of generating a chart by calling the server, it is necessary to ensure that the chart file stream in the current page has been completely sent back to the server, record the return log, and close the browser process. If using PhantomJS, this can only be perceived when the page rendering fails, through the HTTP response code 500. However, if the page rendering is normal but the AJAX return is abnormal, it cannot be perceived based on the HTTP request-response model. Selenium provides a page DOM probe technology. This feature can be used to continuously probe the successful DOM nodes agreed upon with the front end in advance. If the probe is successful, it can be accurately known that the chart file stream of the current page has been successfully returned, and the next operation can be performed.

[0040] (3) Using Selenium to schedule front-end pages is less intrusive to business logic compared to using PhantomJS to simulate browser behavior. Only one Selenium dependency is needed to communicate directly with the browser, while PhantomJS requires a series of command-line support dependencies, greatly simplifying server-side configuration.

[0041] (4) Selenium has a more complete ecosystem than PhantomJS, and its subsequent technical support and upgrades are more guaranteed. Attached Figure Description

[0042] Figure 1 This is a system architecture diagram for generating graphical reports based on server-side calls in an embodiment of the present invention.

[0043] Figure 2 This is a flowchart illustrating the method for generating graphical reports based on server-side calls in this embodiment of the invention. Detailed Implementation

[0044] Figure 1 This is a system architecture diagram for generating graphical reports based on server-side calls in an embodiment of the present invention. The system architecture includes three main modules: server-side report service module, front-end chart service, and scheduling platform.

[0045] The server-side reporting service module mainly includes three sub-modules: report data service, report generation service, and report preview service.

[0046] The core functions of report data services are mainly twofold:

[0047] a) Provides data support for front-end chart generation;

[0048] b) Provide data support for the report documents required for the report generation service;

[0049] The report generation service has three main core functions:

[0050] a) Provide an interface to store the chart file stream returned from the front end;

[0051] b) Call the report data service interface to obtain the data required for the report text and fill in the corresponding text positions in the general template;

[0052] c) Fill the corresponding positions in the template with the chart file stream sent back from the front end, and regenerate a new report.

[0053] (.docx);

[0054] The core function of the report preview service is to provide an interface for obtaining front-end report previews;

[0055] The front-end chart service module mainly consists of two sub-modules: chart generation service and report preview service.

[0056] The core function of the chart generation service is to implement functions such as rendering, monitoring, file-based chart pages, and sending back to the file server based on the Echarts open-source library.

[0057] The core function of the report preview service is to call the server-side report file retrieval interface to provide online preview of the report and custom selection of report modules. The online preview is mainly implemented based on the PDF preview plugin provided by the web browser.

[0058] The core function of the scheduling platform module is to periodically invoke the report generation service and use Selenium technology to proactively trigger the front-end page to complete a series of subsequent report generation actions.

[0059] Figure 2 This is a flowchart illustrating the method for generating graphical reports based on server-side calls in this embodiment of the invention. The specific steps include:

[0060] Step 201: This step is a preparation step, which mainly includes installing the browser on the remote server and installing the fonts required to generate the chart. If the font is missing, it may cause a font to be garbled on the chart.

[0061] Step 202: Utilize the scheduling platform to activate the task in the report generation service that periodically triggers the front-end page. Specifically, the server imports the relevant Selenium dependencies and configures the driver corresponding to the browser version installed on the remote server. The server calls the SDK provided by the Selenium dependency package to communicate with the browser on the remote server, creating a browser access process. The program automatically inputs the URL provided by the front-end chart generation service, triggering the front-end page to load.

[0062] The specific implementation is as follows:

[0063] 1) Install the Selenium library and include the WebDriver 3.x component (WebDriver is an API and protocol that defines a language-neutral interface for controlling the behavior of web browsers). In this case, we use Maven to reference the selenium-java jar package dependency to complete the installation.

[0064] 2) Download the driver version corresponding to your local web browser from the official Selenium Manager website, and use System.setProperty("webdriver.chrome.driver",driverFile) to load the local driver;

[0065] 3) Use ChromeOptions to obtain the necessary parameters for controlling the behavior of the web browser in WebDriver, and use newChromeDriver(ChromeOptions) to initialize WebDriver;

[0066] 4) Call the WebDriver.get() SDK method provided by WebDriver to create a server application that communicates with the web browser, create a browser access process, control the web browser to automatically input the URL for generating the graphical report provided in step 2, and thus trigger the graphical report rendering process created in step 2.

[0067] 5) The graphical report page uses echarts to render the graphical report and listens for the rendering completion event. After rendering is complete, the report is fileified and the server upload file interface is called to persist the final generated graphical report to the server file server.

[0068] 6) Call the WebDriverWait and WebDriverWait.until(callBack) SDK methods provided by WebDriver to periodically detect the page DOM structure provided in step 2, and attempt to obtain the specific DOM nodes required by the server and client to complete page rendering as agreed. If detected, it means that the current page has been successfully rendered. Call the WebDriver.quit() SDK method to disconnect the communication between the server application and the web browser, thus completing this task of actively triggering the client network connection.

[0069] Step 203: The corresponding front-end chart generation page begins loading. First, it calls the interface provided by the report data service to obtain the data required for the chart. The front-end uses various APIs provided by Echarts to configure and render the chart as needed. After rendering, it calls the save interface provided by the report generation service to send the chart file stream back to the server. The specific implementation of graphical report rendering using Echarts, an open-source visualization chart library based on JavaScript, is as follows:

[0070] 1) Use npm to import the React version of the Echarts open-source library, and import ECharts charts and components as needed to implement graphical report rendering.

[0071] 2) Initialize Echarts using `var myChart = echarts.init(document)` and configure the chart rendering function.

[0072] Service Required Themes

[0073] 3) When the web browser triggers the rendering of the graphical report, it calls the server-side API data interface during page initialization to obtain the business data necessary for rendering the graphical report and synchronously sets the number of graphical reports (imageSize) to be rendered on the page.

[0074] 4) Use the myChart.on('finished', function) event to listen for the completion of the graphical report rendering.

[0075] 5) Use myChart.getDataURL() to convert the chart report into a Base64 file stream, thereby enabling the chart report to be file-based and facilitating subsequent transmission of the chart report back to the server.

[0076] 6) Call the service's file saving API interface to persist the graphical report to the server-side file server and record the upload results in the uploadDatas collection.

[0077] Step 204: Operations personnel create a general report template (.doxc) in advance, which mainly includes the general style and content of the report, and anchors the data variables and chart positions. The server-side report generation service calls the report data service interface to obtain the data required for the report text and populates it into the corresponding anchors.

[0078] Step 205: The report generation service uses Poi-tl open-source technology to populate the chart file generated by the front end in step 203 with the corresponding common anchor points, and regenerates a new report (.docx), which is then stored in the file system and awaits retrieval by the front end preview service.

[0079] Although embodiments of the present invention have been shown and described above, it is understood that the above embodiments are exemplary and should not be construed as limiting the present invention. Those skilled in the art can make changes, modifications, substitutions and variations to the above embodiments within the scope of the present invention without departing from the principles and spirit of the present invention.

Claims

1. A method for generating graphical reports based on server-side calls, characterized by the following steps: as follows: Step 1: Based on a Linux server, install a web browser on the server and install the system fonts required for rendering graphical reports on the server; Step 2: Front-end web coding to implement chart generation functions, including calling the server-side interface to obtain the data required for the chart during page initialization, using Echarts technology to draw the chart, and calling the relevant Echarts API to convert the chart into a file stream and send it back to the server after the page is loaded, and providing a link to access the server. Step 3: Backend coding, including importing Selenium-related dependencies and configuring the corresponding browser driver installed on the remote server; The server calls the SDK provided by Selenium, uses the driver to communicate with the server browser, creates a server browser access process, and accesses the link provided in Step 2 to complete the call to the frontend page; Step 4: Configure the program to generate a general .docx format report template. Using anchor point technology and the open-source technology Poi-tl, insert the chart files returned by the front end in Step 3 into the corresponding positions in the report, and regenerate a new .docx format report. In step 2: Based on the React client framework, the Echarts open-source library is used to implement the rendering, monitoring, file-based graphical reports, and file-back to the file server; the process is as follows: Use npm to import the React version of the Echarts open-source library; Use the init method provided by Echarts to initialize the graphical report and generate rendering settings; Use the rendering completion listener provided by Echarts to monitor the rendering process; After rendering is complete, use the getDataURL method provided by Echarts to file the report; Call the server-side file upload interface to persist the graphical report to the file server; Step 3: Based on Java server-side coding, Selenium WebDriver 3.x is used to implement the server-side application to control the behavior of the web browser, actively render the graphical report provided in Step 2 in the web browser to generate a URL, and then trigger the graphical report created in Step 2 to be persisted to the server file server. At the same time, a series of SDK methods provided by Selenium are called to complete the listening for the page rendering completion and disconnect the communication between the server-side application and the web browser. The process is as follows: Using Maven dependency management, the Selenium WebDriver 3.x library package is included in the server-side configuration. The server-side uses a Selenium Manager driver that matches the local web browser version; The `new ChromeDriver(ChromeOptions)` function completes the initialization of WebDriver, including loading the driver location and setting web browser access. Call the WebDriver.get() SDK method provided by WebDriver to establish communication between the server and the web browser, and automatically trigger the generation and rendering of the graphical report URL; The graphical report generation page renders the graphical report. After rendering is complete, the report is file-based and persisted to the server file server. WebDriver's `quit` function shuts down communication between the server and the web browser, releasing resources. In step 3, in order to achieve the rational allocation and utilization of server resources and the effect of quickly reversing the entire server-side call to generate graphical reports, Selenium is used to provide a page DOM probe technology. The server continuously probes the successful DOM nodes agreed upon with the front end in advance. If the probe is successful, it can accurately know that the current page chart file stream has been returned normally. Then, the communication channel established between the current server and the web browser is closed, so as to achieve the effect of server resource scheduling and allocation and the reversal of the overall process in the next step. The server and client agree on two specific DOM nodes for the page: imageSize (the number of graphic reports rendered on the page) and uploadDatas (the set of results returned by the server's file persistence interface for the graphic reports). The Selenium WebDriver 3.x component is used to establish communication between the server and the web browser, scheduling and triggering the rendering of the chart report generation page on the web browser. At this time, the chart report generation page requests the server's API data interface to obtain the business data necessary for generating the chart report. Based on the data structure returned by the server, the number of chart reports generated on the current page, imageSize, is set. If data retrieval fails, imageSize is set to -1. When the echarts myChart.on('finished', function) event is used to listen for the completion of rendering of a chart report, myChart.getDataURL() is called to convert the chart report into a Base64 file stream. At the same time, the server's upload method is called to persist the chart report data to the server's file server, and the result returned by the upload method is recorded in the uploadDatas collection. The server uses the Selenium WebDriverWait.until(callBack) SDK method to detect the values ​​of imageSize and uploadDatas.size() every second. When imageSize is found to be -1, it indicates that the rendering of the current graphical report has failed. The WebDriver.quit() SDK method is called to disconnect the server application from the web browser and record the failure for subsequent retry. When imageSize and uploadDatas.size() are found to be equal, it indicates that the batch generation of graphical reports has been completed. Communication between the server and the web browser is closed, and resources are released. Using a scheduling platform, a task that periodically triggers the front-end page is activated within the report generation service. Specifically, the server imports Selenium dependencies and configures drivers corresponding to the browser version installed on the remote server. The server then uses the SDK provided by the Selenium dependency package to communicate with the browser on the remote server, creating a browser access process. The program automatically inputs the URL provided by the front-end chart generation service, triggering the front-end page to load. The specific implementation is as follows: Install the Selenium library and include the WebDriver 3.x component. WebDriver is an API and protocol that defines a language-neutral interface for controlling the behavior of web browsers. Use Maven to include the selenium-java jar package dependency to complete the installation. Download the driver version corresponding to your local web browser from the official Selenium Manager website, and use System.setProperty("webdriver.chrome.driver", driverFile) to load the local driver; Use ChromeOptions to obtain the necessary parameters for controlling the behavior of the web browser using WebDriver, and use newChromeDriver(ChromeOptions) to initialize WebDriver. Call the WebDriver.get() SDK method provided by WebDriver to create a server application that communicates with the web browser, create a browser access process, control the web browser to automatically input the URL for generating the graphical report provided in step 2, and thus trigger the graphical report rendering process created in step 2. The graphical report page uses echarts to render the graphical report and listens for the rendering completion event. After rendering is complete, the report is file-based, and the server-side file upload interface is called to persist the final generated graphical report to the server-side file server. The WebDriverWait and WebDriverWait.until(callBack) SDK methods provided by WebDriver are invoked to periodically probe the DOM structure of the page provided in step 2, attempting to obtain the specific DOM nodes required by the server and client to complete page rendering as agreed. If detected, it indicates that the current page has been successfully rendered. The WebDriver.quit() SDK method is then called to disconnect the communication between the server application and the web browser, completing this task of actively triggering the client network connection.

Images