Webpage-to-PDF conversion method, device, equipment, medium and product
By writing task parameters to a message queue middleware and ending the HTTP connection, and by adopting asynchronous processing and a producer-consumer architecture, the problem of webpage to PDF conversion task failure in high-concurrency scenarios is solved, achieving a stable conversion process and a high success rate.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- BEIJING SHANGRUITONG TECHNOLOGY CO LTD
- Filing Date
- 2026-02-13
- Publication Date
- 2026-06-02
AI Technical Summary
In high-concurrency scenarios, webpage-to-PDF conversion tasks are prone to failure, mainly due to server resource exhaustion and service avalanche caused by HTTP connection timeouts.
Asynchronous processing is achieved by writing the task parameters of the webpage to PDF conversion task request into the message queue middleware in sequence and ending the HTTP connection. The rendering service process, which adopts a producer-consumer architecture, executes the conversion operation in sequence and re-establishes the HTTP connection to receive the result after obtaining the PDF result.
It effectively solves the problem of server resource exhaustion and HTTP connection timeouts causing task failures under high concurrency, realizes a stable webpage to PDF processing flow, avoids service avalanche, and improves task success rate.
Smart Images
Figure CN122132357A_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a method, apparatus, device, medium, and product for converting web pages to PDF. Background Technology
[0002] With the development of industries such as online education and e-government, the demand for converting dynamic web pages (such as HyperText Markup Language (HTML), reports, e-invoices, etc.) into standard Portable Document Format (PDF) documents is growing. These web pages often contain complex charts (such as Echarts, Highcharts), images, and dynamic layouts, requiring a full browser rendering engine to accurately reproduce them.
[0003] In related technologies, webpage-to-PDF services typically use synchronous Hypertext Transfer Protocol (HTTP) requests. PDF rendering is a CPU- and memory-intensive operation, with individual tasks taking a long time (from several seconds to several minutes). In high-concurrency scenarios, a large number of synchronous HTTP requests can instantly exhaust server thread resources and memory, causing server timeouts or even crashes, thus leading to the failure of the webpage-to-PDF task. Summary of the Invention
[0004] This invention provides a method, apparatus, device, medium, and product for converting web pages to PDF, in order to solve the problem that web page to PDF conversion tasks are prone to failure in high-concurrency scenarios.
[0005] In a first aspect, embodiments of the present invention provide a method for converting web pages to PDF, comprising: It receives webpage-to-PDF task requests from each client via each HTTP connection and determines the corresponding task parameters for each task request. Write the task parameters into the message queue middleware in order, and then terminate the corresponding HTTP connection; According to the order of the task parameters in the message queue middleware, the conversion operation is performed sequentially based on each task parameter to obtain the PDF result; Establish an HTTP connection, send the PDF results back to the corresponding client via the HTTP connection, and update the message queue middleware.
[0006] In one possible implementation, the step of sequentially performing conversion operations based on each task parameter in the message queue middleware to obtain the PDF result includes: According to the order of the task parameters in the message queue middleware, at least one rendering service process is called to perform the conversion operation based on each task parameter in turn to obtain the PDF result; Each rendering service process performs a conversion operation based on the task parameters corresponding to a task request at the same time.
[0007] In one possible implementation, a conversion operation is performed based on each task parameter to obtain a PDF result, including: For each task request, the rendering service process performs a webpage loading operation based on the task parameters corresponding to the task request, and monitors the webpage loading status in real time. Once the webpage has finished loading, the rendering operation is performed to obtain the PDF result.
[0008] In one possible implementation, the PDF result is sent back to the corresponding client via an HTTP connection, including: The PDF results are uploaded to object storage, and the corresponding access link is obtained; An HTTP request is sent to the corresponding client via the HTTP connection, and the HTTP request contains the access link.
[0009] In one possible implementation, the task parameters include a task ID, and the message queue middleware contains the task ID corresponding to each task request; Updating the message queue middleware includes: In the message queue middleware, delete the task ID corresponding to the PDF result.
[0010] In one possible implementation, the task parameters corresponding to each task request include: the task ID and configuration parameters corresponding to each task request; After determining the task parameters corresponding to each task request, the following is also included: Write the task ID and configuration parameters corresponding to each task request into the preset database; The step of writing the task parameters into the message queue middleware in sequence includes: Write the task IDs corresponding to each task request into the message queue middleware in order; The step of performing conversion operations sequentially based on the task parameters in the message queue middleware to obtain PDF results includes: According to the order of each task ID in the message queue middleware, the corresponding configuration parameters are retrieved from the database in sequence, and the conversion operation is performed based on the configuration parameters to obtain the PDF result.
[0011] Secondly, embodiments of the present invention provide a webpage to PDF conversion device, comprising: The acquisition module is used to receive webpage to PDF task requests from each client via each HTTP connection, and determine the corresponding task parameters for each task request. Write the task parameters into the message queue middleware in order, and then terminate the corresponding HTTP connection; The processing module is used to perform conversion operations sequentially based on the task parameters in the message queue middleware to obtain PDF results. The callback module is used to establish an HTTP connection, send the PDF results back to the corresponding client via the HTTP connection, and update the message queue middleware.
[0012] Thirdly, embodiments of the present invention provide an electronic device, including a memory and a processor, wherein the memory stores a computer program, and the processor executes the computer program to implement the method described in the first aspect or any possible implementation thereof.
[0013] Fourthly, embodiments of the present invention provide a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method described in the first aspect or any possible implementation thereof.
[0014] Fifthly, embodiments of the present invention provide a computer program product, including a computer program that, when executed by a processor, implements the method described in the first aspect or any possible implementation thereof.
[0015] In high-concurrency scenarios, the server receives a large number of webpage-to-PDF conversion requests. This invention decouples task requests and task processing by sequentially writing the task parameters corresponding to each request into a message queue and closing the corresponding HTTP connection, thus achieving asynchronous processing. Then, the conversion operation is executed sequentially according to the order of the task parameters in the message queue middleware to obtain the PDF result. A new HTTP connection is then established to send the PDF result back to the client. This achieves an asynchronous "receive-enqueue-process" flow, avoiding the situation where the server processes multiple tasks simultaneously and completely resolving the service avalanche problem under high concurrency.
[0016] Furthermore, in existing synchronous processing methods, the client maintains an HTTP connection indefinitely to wait for the PDF result. However, HTTP connections have timeout limits, and the server's synchronous processing speed is too slow, easily leading to conversion failures due to connection timeouts. The embodiments of this invention, by ending the HTTP connection after writing the task parameters to the queue and re-establishing the HTTP connection after obtaining the PDF result, can further solve the problem of task failures caused by HTTP connection timeouts. Attached Figure Description
[0017] Figure 1 This is a software architecture diagram of the webpage to PDF conversion method provided in this embodiment of the invention; Figure 2 This is a flowchart illustrating the implementation of the webpage-to-PDF conversion method provided in this embodiment of the invention. Figure 3 This is a flowchart illustrating the logic of waiting for a webpage to finish loading in an embodiment of the present invention. Figure 4 This is a timing diagram of the webpage to PDF conversion method provided in an embodiment of the present invention; Figure 5 This is a schematic diagram of the webpage-to-PDF conversion device provided in an embodiment of the present invention; Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. Detailed Implementation
[0018] The embodiments of the present invention will now be described in detail with reference to the accompanying drawings.
[0019] Most related technologies employ a simple web service interface to perform the webpage-to-PDF conversion task. Specifically, the client calls an HTTP-based API interface (e.g., a POST / convert interface) through an Application Programming Interface (API) gateway, sending the webpage URL (Uniform Resource Locator, URL) to the server. The server then directly launches a headless browser (e.g., a Puppeteer / PhantomJS process), which loads and renders the webpage, generating a PDF binary stream. Finally, the PDF binary stream is returned directly to the client user via an HTTP response.
[0020] The above scheme is synchronous and tightly coupled. If there are 100 simultaneous requests to convert web pages to PDF, the server will attempt to launch 100 headless browsers at the same time, causing memory to be exhausted instantly, service unavailability, and consequently, failure of the web page to PDF conversion task. Furthermore, when the client calls the API interface based on the HTTP protocol (also known as the HTTP interface), an HTTP connection is established for data transmission. However, HTTP connections typically have timeout limits (e.g., 60 seconds). If the web page is too complex (e.g., containing complex icons, images, etc.), the rendering time of the headless browser will inevitably be extended accordingly, leading to task failure due to timeout.
[0021] To improve the success rate of webpage-to-PDF conversion in high-concurrency scenarios (i.e., scenarios where a large number of users simultaneously initiate webpage-to-PDF conversion requests within a short period of time), this embodiment of the invention writes the task parameters corresponding to each task request into a message queue in sequence and terminates the corresponding HTTP connection. This decouples task requests from task processing, enabling asynchronous processing. Then, the conversion operation is executed sequentially according to the order of the task parameters in the message queue middleware to obtain the PDF result. A new HTTP connection is then established to send the PDF result back to the client. This achieves an asynchronous "receive-enqueue-process" flow, avoiding situations where the server processes multiple tasks simultaneously and completely resolving the service avalanche problem under high concurrency.
[0022] Furthermore, in this embodiment of the invention, the HTTP connection is terminated after the task parameters are written to the queue, and the HTTP connection is re-established and a callback is made after the PDF result is obtained, which can further solve the problem of task failure caused by HTTP connection timeout.
[0023] Figure 1 This is a software architecture diagram of the webpage-to-PDF conversion method provided in an embodiment of the present invention. Figure 1 As shown, the software architecture includes: a task submission module (i.e., API gateway), a task scheduling module (i.e., message queue middleware), a state management module (i.e., database), a rendering engine module (i.e., rendering service process), and a storage and notification module.
[0024] The task submission module (i.e., the API gateway) can receive webpage-to-PDF task requests sent by users through the client, perform parameter validation, and generate a globally unique task ID. It's important to note that the task request includes configuration parameters such as the target webpage URL and callback address. The task submission module can obtain these configuration parameters by parsing the task request.
[0025] The task scheduling module (i.e., message queue middleware) is mainly used for task buffering, distribution, and backlog processing. The task IDs of each task request can be written into the message queue middleware in sequence. The message queue middleware stores the task IDs in sequence and distributes them to the rendering engine module in sequence to decouple task requests and task processing, avoiding the rendering engine module from processing multiple task requests simultaneously.
[0026] The rendering engine module (i.e., the rendering service process) is responsible for loading and rendering web pages, generating PDF results. Here, the rendering service process can be a rendering cluster based on a headless browser.
[0027] The Storage and Notification module includes object storage and an HTTP callback service. It can upload PDF results to object storage, generate access links, and use the HTTP callback service to send the access links back to the client.
[0028] The state management module (i.e., the database) is used to store the entire lifecycle state of task requests. The task ID, configuration parameters, and task status of each task request can all be stored in the state management module. Here, task status can include multiple states such as "Todo," "Doing," "Done," and "Error."
[0029] The execution entity of the webpage to PDF conversion method provided in this embodiment of the invention can be a server, and the server runs... Figure 1 The software architecture shown is used to implement a method for converting web pages to PDFs.
[0030] See Figure 2 The document illustrates a flowchart of the webpage-to-PDF conversion method provided in this embodiment of the invention, detailed below: Step 201: Receive webpage to PDF conversion task requests from each client via each HTTP connection, and determine the corresponding task parameters for each task request.
[0031] In this embodiment of the invention, the client calls the HTTP interface through the API gateway in the server to create an HTTP connection, thereby interacting with the server to transmit the webpage to PDF task request to the server.
[0032] Here, the task request includes configuration parameters such as the webpage address (front_url) and the callback address (callback_url). The webpage address is the webpage to be converted to PDF, and the callback address is the client's HTTP address, which the server uses to send the PDF result back to the client after obtaining it.
[0033] The API gateway parses task requests to obtain configuration parameters such as webpage addresses and callback addresses, as well as business identifiers such as business IDs, and generates globally unique task IDs. It's important to clarify that the task ID, generated by the API gateway, is primarily used on the server side to uniquely identify each webpage-to-PDF task. The business ID (e.g., user order number, report ID, etc.) is passed in by the client and is primarily used on the client side to uniquely identify each business transaction. This allows the server-generated PDF result to be bound to the corresponding business transaction, explicitly notifying the client that the webpage-to-PDF request for that business transaction has been completed.
[0034] As described above, the task parameters corresponding to each task request include: the task ID and configuration parameters corresponding to each task request. In some embodiments, after determining the task parameters corresponding to each task request, the task ID and configuration parameters corresponding to each task request can be written into a preset database.
[0035] In addition to the task ID and configuration parameters mentioned above, this embodiment of the invention can also store parameters such as task status and business ID in the database to achieve persistent storage of each task request, prevent data loss in the message queue middleware, and use it for subsequent status tracking. It is understood that the task status parameter can be initialized to "pending execution" and stored in the database.
[0036] For example, the preset database can be MySQL, PostgreSQL, pure Redis, or MongoDB. Taking MongoDB as an example, in this embodiment of the invention, the DBS.render_task.insertOne command can be used to write the above task parameters into MongoDB.
[0037] Step 202: Write the task parameters into the message queue middleware in order and close the corresponding HTTP connection.
[0038] In this embodiment of the invention, the task parameters corresponding to each task request can be encapsulated into a message, and the task parameter message can be sent to the message queue middleware in the order of receiving each task request, thereby writing each task parameter into the message queue middleware in sequence.
[0039] In some embodiments, to save resources, the task IDs corresponding to each task request can be written to the message queue middleware in sequence. That is, the task IDs corresponding to each task request are encapsulated into messages, and the messages corresponding to each task ID are sent to the message queue middleware for storage in the order in which the task requests are received.
[0040] For example, the message queue middleware can be Kafka, RocketMQ, Redis List (LPUSH / RPOP), or RabbitMQ. Taking RabbitMQ as an example, this embodiment of the invention can use the web2pdf_ai_report_pdf_render command to send the messages corresponding to each task ID to RabbitMQ storage.
[0041] In this embodiment of the invention, after storing the task ID in the message queue middleware, the task ID can be returned to the client to notify the client that the server has established the corresponding webpage to PDF task. Simultaneously, the HTTP connection between the server and the client is terminated.
[0042] In this embodiment of the invention, the API gateway in the server can act as a producer, receiving task requests from clients and storing the corresponding task IDs in order in a message queue middleware. Simultaneously, it terminates the HTTP connection, decoupling task requests from task processing and achieving heterogeneous scheduling of task requests. This avoids the service avalanche problem in high-concurrency scenarios caused by traditional synchronous processing methods and also prevents HTTP connection timeouts. This embodiment of the invention bypasses the HTTP connection timeout limit, supporting webpage-to-PDF conversion tasks of any duration and effectively preventing task failures due to HTTP connection timeouts.
[0043] Step 203: Perform the conversion operation sequentially based on the task parameters in the message queue middleware according to the order of each task parameter to obtain the PDF result.
[0044] In some embodiments, at least one rendering service process can be invoked sequentially to perform conversion operations based on each task parameter in the order of the task parameters in the message queue middleware, so as to obtain the PDF result.
[0045] The server can run at least one rendering service process. Each rendering service process listens to the message queue middleware in real time. The message queue middleware can distribute each task ID sequentially to the above-mentioned at least one rendering service process, so that the rendering service process can execute the webpage to PDF operation corresponding to the task ID and obtain the PDF result.
[0046] Here, the rendering service process acts as a "consumer," performing the webpage-to-PDF conversion operation based on the task ID distributed by the message queue middleware, and obtaining the PDF result. This embodiment of the invention, by adopting a "producer-consumer" architecture, decouples the task requests and task processing in the webpage-to-PDF task, thus processing each task request sequentially and avoiding the avalanche problem caused by processing multiple task requests simultaneously in high-concurrency scenarios. Even if 10,000 requests flood in instantly, this embodiment of the invention can process them one by one at a constant rate (determined by the number of consumers) without crashing due to resource exhaustion.
[0047] It should be noted that each rendering service process performs a conversion operation based on the task parameters corresponding to a single task request at the same time. In this embodiment of the invention, the channel.prefetch(1) instruction can be used to set parameters for each rendering service process so that each rendering service process processes only one task request at a time, thus preventing memory overflow.
[0048] `channel.prefetch(1)` means that the message queue middleware will not push a new task ID to the rendering service process until it has finished processing the current task request. This is crucial for browser rendering scenarios that consume a lot of memory, and can effectively prevent server resources from being exhausted. This embodiment of the invention can achieve precise load control of backend resources by limiting the processing capacity of each consumer.
[0049] As described above, the message queue middleware only stores the task IDs. The configuration parameters corresponding to each task ID are stored in the database. Accordingly, in some embodiments, the rendering service process can retrieve the corresponding configuration parameters from the database sequentially according to the order of the task IDs in the message queue middleware, and perform a conversion operation based on the configuration parameters to obtain the PDF result.
[0050] In some embodiments, for each task request, the rendering service process performs a webpage loading operation based on the task parameters corresponding to the task request and monitors the webpage loading status in real time; when it is determined that the webpage has finished loading, it performs a rendering operation to obtain a PDF result.
[0051] For each task ID in the message queue middleware, when the rendering service process performs a transformation operation based on that task ID, it can first retrieve the configuration parameters corresponding to that task ID from the database. Then, it can perform a webpage loading operation based on the configuration parameters and monitor the webpage loading status in real time. Once it is determined that the webpage has finished loading, it can perform a rendering operation to obtain the PDF result.
[0052] Here, the rendering service process can call a headless browser, enabling the headless browser to load and render the webpage to obtain a PDF result. During the loading of the target URL (i.e., the webpage address), the headless browser can monitor the webpage loading status in real time using the front-end code of the target webpage. Once it determines that the webpage has finished loading, it performs the rendering operation to obtain the PDF result.
[0053] For example, a headless browser can be Playwright, Selenium, PhantomJS, or Puppeteer.
[0054] Specifically, see Figure 3 After confirming that all charts and images on the target webpage have finished loading, the front-end code will set a specific flag to 1 (e.g., window.renderFlag === 1). This embodiment of the invention can detect whether the webpage has finished loading by monitoring this specific flag in real time. When window.renderFlag === 1, it is determined that the webpage has finished loading, triggering page.pdf() to perform the rendering operation and obtain the PDF result.
[0055] `renderFlag` is a protocol agreed upon by the front-end and back-end. After executing all AJAX requests and chart rendering animations, the front-end code of the target webpage sets `window.renderFlag` to 1. The back-end Puppeteer script blocks and waits for this value to change via `page.waitForFunction`. This is a key technology for ensuring the accuracy of dynamic webpage rendering.
[0056] Traditional webpage loading and rendering operations typically begin at a set interval (e.g., 5 or 10 seconds) after the webpage has started loading. This results in wasted time for simple webpages, and for complex webpages, rendering may occur before the webpage has fully loaded, leading to missed content and incomplete PDF results.
[0057] The embodiments of the present invention perform rendering operations by monitoring the webpage loading status in real time. This allows the webpage front-end code to actively notify the back-end after the webpage is loaded, ensuring that the webpage content is fully loaded before performing the rendering operation. This not only avoids missing content on the webpage but also avoids wasting time.
[0058] This invention does not rely on a fixed set interval, but instead uses the window.renderFlag mechanism to listen to global variables in the webpage context (such as window.renderFlag) to accurately determine when dynamic content (such as complex charts) has finished loading. This effectively solves the problems of "blank PDF" or "incomplete PDF" caused by network fluctuations, complex webpages, or incomplete chart animations in traditional solutions.
[0059] In this embodiment of the invention, after launching the headless browser, parameters can be configured for the headless browser, and the configured headless browser can be used to load and render web pages to obtain PDF results. For example, the headless browser can be adapted to the server environment by configuring the parameter `--no-sandbox`, and the `--disable-dev-shm-usage` parameter can be configured to prevent insufficient shared memory.
[0060] Furthermore, in this embodiment of the invention, when the rendering service process is invoked to process the task ID, the task status corresponding to the task ID in the database can be updated to "in execution".
[0061] Step 204: Establish an HTTP connection, send the PDF results back to the corresponding client via the HTTP connection, and update the message queue middleware.
[0062] In some embodiments, the PDF result can be uploaded to object storage (i.e., cloud storage) and a corresponding access link can be obtained; then, an HTTP request is sent to the corresponding client via an HTTP connection. The HTTP request contains the access link.
[0063] After obtaining the PDF result, this embodiment of the invention can upload the PDF result to object storage and simultaneously obtain the corresponding permanent access link. Next, the permanent access link is saved to the database, and the task status corresponding to the task ID in the database is updated to "completed". Subsequently, an HTTP connection is established based on the callback address, and an HTTP request is sent to the client. This HTTP request contains the permanent access link and task status corresponding to the PDF result. Furthermore, the HTTP request may also include the business ID corresponding to the PDF result for subsequent processing by the client.
[0064] For example, embodiments of the present invention can send a POST request to the client's callback address (callback_url) via HttpUtils.postRes, thereby sending the PDF result back to the client.
[0065] After successfully sending the PDF result back to the client, this embodiment of the invention can update the message queue middleware. In some embodiments, the task ID corresponding to the PDF result can be deleted from the message queue middleware to achieve the purpose of updating the message queue middleware.
[0066] Here, in this embodiment of the invention, an ACK confirmation can be sent to the message queue middleware (RabbitMQ) to delete the corresponding task ID in the message queue middleware (RabbitMQ).
[0067] However, if the PDF conversion fails and a PDF result cannot be obtained, a NACK can be sent to the message queue middleware (RabbitMQ), and the task status corresponding to the task ID can be updated to "task error". For failed task IDs, they can be transferred to the dead-letter queue, or the rendering service process can be called again to retry the conversion operation.
[0068] The following is combined with Figure 4 This article provides an overview of methods for converting web pages to PDF.
[0069] First, the client submits a task request to the API gateway; Next, the API gateway determines the task ID, configuration parameters, and task status based on the task request and writes them to the database; Then, the task ID is written to the message queue middleware to enqueue the task; Next, the message queue middleware pushes each task ID to the rendering service process; Furthermore, the rendering service process calls the headless browser to perform webpage loading and rendering operations, and obtains the PDF result; Finally, the PDF result is uploaded to object storage, and the access link for the PDF result is sent back to the client. Finally, update the task status corresponding to the task ID.
[0070] In high-concurrency scenarios, the server receives a large number of webpage-to-PDF conversion requests. This invention decouples task requests and task processing by sequentially writing the task parameters corresponding to each request into a message queue and closing the corresponding HTTP connection, thus achieving asynchronous processing. Then, the conversion operation is executed sequentially according to the order of the task parameters in the message queue middleware to obtain the PDF result. A new HTTP connection is then established to send the PDF result back to the client. This achieves an asynchronous "receive-enqueue-process" flow, avoiding the situation where the server processes multiple tasks simultaneously and completely resolving the service avalanche problem under high concurrency.
[0071] Furthermore, in existing synchronous processing methods, the client maintains an HTTP connection indefinitely to wait for the PDF result. However, HTTP connections have timeout limits, and the server's synchronous processing speed is too slow, easily leading to conversion failures due to connection timeouts. The embodiments of this invention, by ending the HTTP connection after writing the task parameters to the queue and re-establishing the HTTP connection after obtaining the PDF result, can further solve the problem of task failures caused by HTTP connection timeouts.
[0072] It should be understood that the sequence number of each step in the above embodiments does not imply the order of execution. The execution order of each process should be determined by its function and internal logic, and should not constitute any limitation on the implementation process of the embodiments of the present invention.
[0073] The following are device embodiments of the present invention. For details not described in detail, please refer to the corresponding method embodiments described above.
[0074] Figure 5 A schematic diagram of the webpage-to-PDF conversion device provided in an embodiment of the present invention is shown. For ease of explanation, only the parts related to the embodiment of the present invention are shown, and are described in detail below: like Figure 5 As shown, the webpage to PDF conversion device 5 includes: an acquisition module 51, a processing module 52, and a callback module 53.
[0075] The acquisition module 51 is used to receive webpage to PDF task requests from each client via each HTTP connection, and determine the corresponding task parameters for each task request. Write the task parameters into the message queue middleware in order and close the corresponding HTTP connection. Processing module 52 is used to perform conversion operations sequentially based on the task parameters in the message queue middleware to obtain PDF results. Callback module 53 is used to establish an HTTP connection, send the PDF results back to the corresponding client via the HTTP connection, and update the message queue middleware.
[0076] In one possible implementation, processing module 52 is specifically used for: According to the order of the task parameters in the message queue middleware, at least one rendering service process is called to perform the conversion operation based on each task parameter in turn to obtain the PDF result; Each rendering service process performs a conversion operation based on the task parameters corresponding to a task request at the same time.
[0077] In one possible implementation, processing module 52 is specifically used for: For each task request, the rendering service process performs a webpage loading operation based on the task parameters corresponding to the task request, and monitors the webpage loading status in real time. Once the webpage has finished loading, the rendering operation is performed to obtain the PDF result.
[0078] In one possible implementation, callback module 53 is specifically used for: Upload the PDF results to object storage and obtain the corresponding access link; An HTTP request is sent to the corresponding client via an HTTP connection. The HTTP request contains the access link.
[0079] In one possible implementation, the task parameter includes the task ID, and the message queue middleware contains the task ID corresponding to each task request. Callback module 53 is specifically used for: In the message queue middleware, delete the task ID corresponding to the PDF result.
[0080] In one possible implementation, the task parameters corresponding to each task request include: the task ID and configuration parameters corresponding to each task request; Processing module 52 is also used for: Write the task ID and configuration parameters corresponding to each task request into the preset database; Processing module 52 is specifically used for: Write the task IDs corresponding to each task request into the message queue middleware in order; Following the order of task IDs in the message queue middleware, the corresponding configuration parameters are retrieved from the database sequentially, and the conversion operation is performed based on the configuration parameters to obtain the PDF result.
[0081] This device embodiment can be used to implement the above method embodiment, and its technical principle and implementation effect are the same as those of the above method embodiment.
[0082] Figure 6 This is a schematic diagram of an electronic device provided in an embodiment of the present invention. For example... Figure 6 As shown, the electronic device 6 of this embodiment includes a processor 60 and a memory 61. The memory 61 stores a computer program 62. When the processor 60 executes the computer program 62, it implements the steps in the various method embodiments described above. Alternatively, when the processor 60 executes the computer program 62, it implements the functions of each module / unit in the various device embodiments described above.
[0083] For example, computer program 62 may be divided into one or more modules / units, which are stored in memory 61 and executed by processor 60 to complete the present invention. The one or more modules / units may be a series of computer program instruction segments capable of performing a specific function, which describe the execution process of computer program 62 in electronic device 6.
[0084] Electronic device 6 may include, but is not limited to, processor 60 and memory 61. Those skilled in the art will understand that... Figure 6 This is merely an example of electronic device 6 and does not constitute a limitation on electronic device 6. It may include more or fewer components than shown, or combine certain components, or different components. For example, electronic device 6 may also include input / output devices, network access devices, buses, etc.
[0085] The processor 60 can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. The general-purpose processor can be a microprocessor or any conventional processor.
[0086] The memory 61 can be an internal storage unit of the electronic device 6, such as a hard disk or RAM. The memory 61 can also be an external storage device of the electronic device 6, such as a plug-in hard disk, Smart Media Card (SMC), Secure Digital (SD) card, or Flash Card. Furthermore, the memory 61 can include both internal and external storage units of the electronic device 6. The memory 61 is used to store the computer program 62 and other programs and data required by the electronic device 6. The memory 61 can also be used to temporarily store data that has been output or will be output.
[0087] For the sake of simplicity and clarity, only the above-described functional modules / units are used as examples. In practical applications, the functions described above can be assigned to different functional modules / units as needed. These modules / units can be implemented in hardware, software, or a combination of both.
[0088] This invention also provides a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, it implements the methods described in the above-described method embodiments.
[0089] This invention also provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the methods described in the above-described method embodiments.
[0090] Computer programs include computer program code, which can be in the form of source code, object code, executable files, or certain intermediate forms. Computer-readable media can include: any entity or device capable of carrying computer program code, recording media, USB flash drives, portable hard drives, magnetic disks, optical disks, computer memory, read-only memory (ROM), random access memory (RAM), electrical carrier signals, telecommunication signals, and software distribution media, etc.
[0091] In the above embodiments, the descriptions of each embodiment have their own emphasis. Parts not detailed or described in a particular embodiment can be referred to in the relevant descriptions of other embodiments. Unless otherwise specified or in conflict with logic, the terminology and / or descriptions between different embodiments are consistent and can be referenced interchangeably. Technical features in different embodiments can be combined to form new embodiments based on their inherent logical relationships.
[0092] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.
Claims
1. A method for converting web pages to PDF, characterized in that, include: It receives webpage-to-PDF task requests from each client via each HTTP connection and determines the corresponding task parameters for each task request. Write the task parameters into the message queue middleware in order, and then terminate the corresponding HTTP connection; According to the order of the task parameters in the message queue middleware, the conversion operation is performed sequentially based on each task parameter to obtain the PDF result; Establish an HTTP connection, send the PDF results back to the corresponding client via the HTTP connection, and update the message queue middleware.
2. The method for converting web pages to PDF according to claim 1, characterized in that, The step of performing conversion operations sequentially based on the task parameters in the message queue middleware to obtain PDF results includes: According to the order of the task parameters in the message queue middleware, at least one rendering service process is called to perform the conversion operation based on each task parameter in turn to obtain the PDF result; Each rendering service process performs a conversion operation based on the task parameters corresponding to a task request at the same time.
3. The method for converting web pages to PDF according to claim 2, characterized in that, The conversion operation is performed based on the parameters of each task to obtain the PDF result, including: For each task request, the rendering service process performs a webpage loading operation based on the task parameters corresponding to the task request, and monitors the webpage loading status in real time. Once the webpage has finished loading, the rendering operation is performed to obtain the PDF result.
4. The method for converting web pages to PDF according to any one of claims 1-3, characterized in that, The PDF results are sent back to the corresponding client via an HTTP connection, including: The PDF results are uploaded to object storage, and the corresponding access link is obtained; An HTTP request is sent to the corresponding client via the HTTP connection, and the HTTP request contains the access link.
5. The method for converting web pages to PDF according to any one of claims 1-3, characterized in that, The task parameters include the task ID, and the message queue middleware contains the task ID corresponding to each task request. Updating the message queue middleware includes: In the message queue middleware, delete the task ID corresponding to the PDF result.
6. The method for converting web pages to PDF according to any one of claims 1-3, characterized in that, The task parameters corresponding to each task request include: the task ID and configuration parameters corresponding to each task request; After determining the task parameters corresponding to each task request, the following is also included: Write the task ID and configuration parameters corresponding to each task request into the preset database; The step of writing the task parameters into the message queue middleware in sequence includes: Write the task IDs corresponding to each task request into the message queue middleware in order; The step of performing conversion operations sequentially based on the task parameters in the message queue middleware to obtain PDF results includes: According to the order of each task ID in the message queue middleware, the corresponding configuration parameters are retrieved from the database in sequence, and the conversion operation is performed based on the configuration parameters to obtain the PDF result.
7. A webpage to PDF conversion device, characterized in that, include: The acquisition module is used to receive webpage to PDF task requests from each client via each HTTP connection, and determine the corresponding task parameters for each task request. Write the task parameters into the message queue middleware in order, and then terminate the corresponding HTTP connection; The processing module is used to perform conversion operations sequentially based on the task parameters in the message queue middleware to obtain PDF results. The callback module is used to establish an HTTP connection, send the PDF results back to the corresponding client via the HTTP connection, and update the message queue middleware.
8. An electronic device, characterized in that, It includes a memory and a processor, the memory storing a computer program, and the processor executing the computer program to implement the method as described in any one of claims 1 to 6.
9. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 6.
10. A computer program product, characterized in that, It includes a computer program that, when executed by a processor, implements the method as described in any one of claims 1 to 6.