A method, device and storage medium for integration and exception handling of a client printing service component

Abstract

This invention discloses a method, apparatus, device, and storage medium for integrating and handling exceptions in a client-side printing service component. The method includes: obtaining user permission identifiers for permission verification; implementing a layered loading strategy of "lightweight service detection first, heavyweight script loading as a fallback," prioritizing service detection through a first communication port, and automatically loading the core script through a second communication port if detection fails; maintaining a global state object to mark the loading status; encapsulating instance acquisition as an asynchronous programming object, and returning instance or fault guidance information in a non-blocking manner through polling and timeout control. This invention solves the problems of low local printing service loading success rate, lack of permission control, difficult installation and adaptation, incompatibility with front-end frameworks, and lack of failover, increasing the loading success rate to over 99.9%, reducing invalid loading by over 95%, increasing the installation success rate to over 98%, and shortening fault diagnosis time to within 3 minutes.

Description

Technical Field

[0001] This invention relates to the fields of medical informatics and web printing technology, and particularly to a method, apparatus, device, and storage medium for integrating and handling anomalies in a client-side printing service component. Background Technology With the deepening development of medical informatization and paperless office practices, web application systems (such as Hospital Information Systems (HIS), Electronic Medical Records (EMR), Venous Thromboembolism (VTE) Prevention and Control Systems, and Enterprise Resource Planning (ERP) systems) are placing increasingly higher demands on printing functions. This is especially true in the medical field, where high-precision and highly customized printing of various documents is required, including VTE risk assessment scales, anticoagulation therapy records, prescriptions, laboratory reports, and inpatient medical records. Traditional browser-native printing (window.print()) has significant shortcomings in areas such as overprint accuracy, batch printing, and barcode / QR code rendering. Therefore, various client-side local printing service components (or printing plugins) have emerged.

[0002] Among them, CLodop (C-Lodop), as a professional web printing control, has become the mainstream technology choice for current medical information systems and enterprise web printing scenarios due to its powerful capabilities such as pre-printing, batch printing, and paper adaptation. In addition, JSPrintManager and Native Messaging plugins also provide similar functions.

[0003] However, existing general solutions for integrating such client-side printing service components (e.g., for CLodop, typically loading the CLodopfuncs.js script and calling the getCLodop function to obtain an instance) reveal the following common shortcomings when applied to complex hospital intranet environments, modern front-end frameworks, and multi-terminal hybrid deployment scenarios: 1. Single loading strategy: Scripts are typically loaded using only a single network protocol (such as HTTP) and a single port (such as 8000), without combining it with lightweight protocols such as WebSocket for pre-service detection, and without fully adapting to HTTPS secure ports (such as 8443). In complex intranet environments (port occupancy, network policy restrictions, HTTPS deployment), this can easily lead to script loading failures.

[0004] 2. Lack of permission isolation: The lack of a permission filtering mechanism based on user roles, institutions or departments leads to the indiscriminate attempt to load controls for all terminal requests, resulting in the ineffective consumption of resources by unauthorized terminals, increasing the internal network load and potentially causing unnecessary compatibility issues.

[0005] 3. Inaccurate installation guide: The guide cannot detect the specific underlying architecture of the terminal operating system (e.g., x64 / x86), and only provides a download link for a generic installation package. End users (especially healthcare workers) often experience installation failures because they download versions incompatible with their systems, severely impacting the efficiency of business implementation.

[0006] 4. Incompatibility between the calling logic and modern frameworks: Traditional synchronous calling methods conflict with the asynchronous data-driven paradigm of modern front-end frameworks such as Vue and React, easily triggering runtime errors such as "control not ready". Furthermore, the lack of unified asynchronous encapsulation leads to code redundancy and high maintenance costs.

[0007] 5. Lack of failover mechanism: The system only attempts to use a single service port or a single loading path. When the local printing service port changes or becomes abnormal, the system cannot automatically failover, directly causing the printing function to fail and failing to meet business continuity requirements.

[0008] 6. Incomplete operation and maintenance loop: Loading anomalies are only handled in a simple way, lacking a structured error collection and reporting mechanism, resulting in low troubleshooting efficiency and difficulty for operation and maintenance personnel to quickly locate the root cause of the problem.

[0009] Therefore, there is an urgent need to provide an integration and exception handling method for client-side printing service components that can solve the above-mentioned technical problems, so as to improve the reliability, ease of use and maintainability of Web printing functions. Summary of the Invention

[0010] This invention aims to overcome the shortcomings of the prior art and provide a method, apparatus, device, and storage medium for integrating and handling exceptions of client-side printing service components. It aims to solve the technical problems existing in the integration of third-party local printing services in existing web application systems, such as low loading success rate, poor resource management, difficult installation and adaptation, incompatible calling methods, lack of failover and closed-loop operation and maintenance mechanisms.

[0011] The specific technical problem to be solved by this invention is as follows: In existing technologies, web application systems (especially medical information systems, such as VTE prevention and control systems, HIS, EMR, etc.) have a series of interrelated technical defects when integrating client-side local printing service components (including but not limited to CLodop, JSPrintManager, etc.). These defects collectively make it difficult for the reliability, usability, and maintainability of the printing function to meet actual business needs: (a) Loading strategy issues: 1.1 Poor protocol and port compatibility Existing general integration solutions (such as loading the CLodopfuncs.js script and then calling getCLodop) only use a single HTTP protocol and a single default port (such as 8000) to load the script. They do not combine lightweight protocols such as WebSocket for front-end service detection, and they do not adapt to HTTPS security ports (such as 8443). In complex network environments such as hospital intranets and enterprise private networks, the script loading failure rate remains high due to port occupation, network access policy restrictions, and HTTPS mixed content blocking.

[0012] 1.2 Lack of failover mechanism The existing solution lacks failover logic for multiple ports and protocols. When the listening port of the local printing service changes (such as switching from 8000 to 18000) or the service is abnormal, the front-end system cannot automatically adapt to the new port or protocol, which directly leads to the interruption of the printing function and cannot meet the stringent continuity requirements of medical printing services.

[0013] (II) Issues related to access control and resource management: 2.1 Lack of access control isolation The existing solution lacks a permission filtering mechanism and attempts to load the printing component indiscriminately for all terminal requests. This results in a large number of invalid control loading requests from terminals that are not the target organization or are not authorized users, increasing the internal network load, wasting terminal memory resources, and potentially causing unnecessary compatibility conflicts.

[0014] 2.2 Disorganized loading status management The existing solution does not uniformly mark and manage the script loading status, which can easily lead to problems such as repeated loading of the same script and misjudgment of the loading status, resulting in abnormal calls to subsequent components and increasing the complexity and cost of system development and maintenance.

[0015] (III) Installation and compatibility issues: 3.1 Inaccurate installation guide The existing solution does not detect the underlying architecture (x64 / x86) of the terminal operating system and only provides a general installation package download link. When end users such as medical staff install the package, the installation often fails because they download a version that is incompatible with their own system architecture, which seriously affects the efficiency of printing business implementation.

[0016] 3.2 The calling logic is incompatible with modern front-end frameworks. The existing synchronous calling method is in fundamental conflict with the asynchronous data-driven paradigm of modern front-end frameworks such as Vue and React. It is very easy to trigger the runtime error "control not ready". Furthermore, the lack of unified asynchronous encapsulation results in a large number of state judgments and exception handling logic in the business code, with extremely high code redundancy and high maintenance costs.

[0017] (iv) Compatibility and maintainability issues: 4.1 Insufficient browser compatibility The existing solution does not adapt to the impact of different browsers (such as the differences in support for WebSocket in older versions of Firefox, and the differences in support for ActiveX in different versions of IE) on the loading method of the printing component. As a result, some terminals cannot load the component properly, making the printing function unusable.

[0018] 4.2 Exception handling is not closed-loop Existing solutions only handle various anomalies during the loading process (such as loading timeout, component not installed, port connection failure) in a simple way (such as pop-up window prompting "printing failed"), lacking structured error type identification, context information collection and remote reporting mechanisms. When troubleshooting, maintenance personnel cannot quickly locate the root cause of the problem, the troubleshooting time is long, and the maintenance cost is significantly high.

[0019] The objective of this invention is achieved through the following technical solution: According to a first aspect of the present invention, an integration and exception handling method for a client-side printing service component is provided, applied to a web application system, comprising the following steps: Permission verification steps: Obtain the permission identifier of the current terminal user and determine whether it has the permission to call the target printing component. If it does not have the permission, terminate the integration process or switch to the alternative printing solution. Layered loading steps: The layered strategy of "lightweight service detection first, heavyweight script loading as a fallback" is implemented. The layered strategy includes: prioritizing the establishment of a lightweight connection with the local printing service through at least one first communication port for availability detection; if the detection fails, it automatically switches to script loading mode and dynamically loads the core script file of the printing component through at least one second communication port. State management steps: Maintain a global state object to at least represent the loading state of the core script files; Asynchronous instantiation steps: The logic for obtaining the instance of the printing component is encapsulated into an asynchronous programming object. The asynchronous programming object obtains and returns the functional instance of the printing component in a non-blocking manner by polling the global state object and using timeout control, or returns an error object containing fault guidance information when it fails.

[0020] Therefore, the permission verification step, by introducing permission-based verification logic at the loading entry point, achieves fine-grained control over printing service call permissions. Only authorized users, organizations, or roles can trigger subsequent component loading processes, thereby avoiding the invalid resource consumption of unauthorized terminals (e.g., reducing invalid loading requests by approximately 95%), reducing intranet load, and being compatible with unified deployment scenarios involving multiple tenants or departments. Alternative printing solutions (such as native browser printing) serve as fallback measures, ensuring the availability of basic printing functions. The layered loading step adopts a two-layer mechanism of "probe + fallback". Lightweight probes (such as WebSocket connections) have minimal overhead and can quickly detect whether the local printing service is alive. When the probe fails, it automatically degrades to HTTP / HTTPS script loading and supports adaptive switching between multiple ports and protocols. This strategy significantly improves the loading success rate in complex network environments (from approximately 70% in the existing solution to over 99.9%), while also achieving failover. In port change scenarios, the response time is less than 500 milliseconds, ensuring the continuity of printing services. The state management step declares and maintains a global state variable (e.g., LoadJsState) to uniformly mark the stage of the script loading process (e.g., "probing", "loading", "complete"), effectively avoiding problems such as duplicate loading and misjudgment of state, providing a reliable state basis for subsequent asynchronous instance acquisition, and reducing the component call exception rate (from 25% to 0). The asynchronous instantiation step encapsulates the instance acquisition process into a Promise (or async / await) object, perfectly adapting to the asynchronous paradigm of modern front-end frameworks such as Vue and React, completely solving the blocking problem of "control not ready". At the same time, the polling + timeout mechanism ensures the determinism of the acquisition process, and the uniformly encapsulated error object carries fault guidance information (e.g., adaptive installation package address), greatly improving development efficiency and user experience, and reducing the amount of business layer code by more than 70%.

[0021] In some implementations, lightweight service probing in the layered loading step further includes: The racing mode is used to initiate connection requests to multiple different communication ports in parallel. The first successfully established connection is considered a valid probe result, and other connection attempts are terminated. If all connection attempts on all ports fail, the service detection is deemed to have failed, triggering a fallback script loading process.

[0022] Therefore, in scenarios where response speed is critical, such as batch printing, by trying multiple ports simultaneously using Promise.race or similar mechanisms and selecting the port with the fastest response, the average connection establishment time is significantly shortened, thus improving the user experience.

[0023] In some implementations, the script loading mode in the layered loading step further includes: Try loading the script via the default communication port first; If the process fails, the port will be automatically adapted based on the network protocol type of the current web page: if the page uses a secure protocol, the port corresponding to the secure protocol will be switched to for loading; if the page uses a non-secure protocol, the port corresponding to the non-secure protocol will be switched to for loading.

[0024] In some implementations, the fault boot information in the asynchronous instantiation step is generated through the following sub-steps: Analyze the system information of the current terminal to identify its underlying hardware or operating system architecture type; Based on the identified architecture type, retrieve and return the installation package address of the printing component that matches the architecture from the preset mapping relationship.

[0025] As a result, it can automatically identify the terminal architecture (x64 / x86) and dynamically return the corresponding installation package link, completely solving the installation failure problem caused by version incompatibility, increasing the installation success rate from 60% to over 98%, and shortening the installation time to within 2 minutes.

[0026] In some implementations, a terminal environment adaptation step is included before the permission verification step: Parse the user agent information of the current terminal and determine whether the printing component needs to be loaded in the current environment based on the preset compatibility rule set; The compatibility rule set includes at least: identification of specific browser brands and versions, differentiation between mobile and desktop versions, and exemption determination for older browser versions that support native controls.

[0027] This enables fine-grained adaptation to different browsers and versions. For older versions of Internet Explorer that natively support ActiveX technology, loading is directly exempted to avoid unnecessary resource consumption. For mobile devices, the latest versions of Edge, Chrome, and other mainstream browsers, loading is accurately triggered, and loading is required by default in environments where it cannot be recognized, ensuring maximum compatibility.

[0028] In some implementations, during the asynchronous instantiation step, the asynchronous programming object is also used internally for: After successfully obtaining the printing component instance, call its built-in version or status verification interface, and cache the instance in the global scope after the verification is successful. When an instance fails to be retrieved or an operation times out, the error object thrown contains the error type, fault guidance information, and preset fault troubleshooting context data.

[0029] Through the above optimizations, after successfully obtaining the printing component instance, its built-in version or status verification interface (such as checking the availability of the VERSION property or PRINT_INIT method) is called to ensure that the returned instance is complete and usable, avoiding subsequent call errors caused by incomplete instances or version incompatibility; at the same time, the verified instance is cached in the global scope, and subsequent requests can directly reuse it, avoiding the performance loss caused by repeated initialization and multiple loading, and improving the system response speed.

[0030] When instance retrieval fails or operation times out, the thrown error object encapsulates structured fault information, including: error type (such as "load timeout", "component not installed", "port connection failed"), fault guidance information (such as adaptive installation package download address, help document link), and preset fault troubleshooting context data (such as browser version, terminal architecture, global state snapshot). This structured error design allows the front-end business layer to handle errors differently based on the error type (such as timeout prompts for retry, component missing guidance for installation), and users can solve common problems themselves; at the same time, the fault context data provides maintenance personnel with accurate location information, significantly shortening fault troubleshooting time (from an average of 20 minutes to less than 3 minutes), improving system maintainability and user experience.

[0031] In some implementations, the integration and exception handling methods for the client printing service component also include closed-loop operation and maintenance steps: Capture asynchronous instantiation steps and print exceptions during component instance invocation; Collect fault context information, which includes at least one of terminal environment parameters, global state object snapshot, and error type; The collected information is reported to the server through the backend interface to form a traceable fault record.

[0032] As a result, this step enables structured anomaly collection and reporting, allowing operations and maintenance personnel to quickly locate the cause of problems (such as browser version, architecture mismatch, port inaccessibility, etc.) based on the reported logs. The troubleshooting time has been reduced from an average of 20 minutes to less than 3 minutes, significantly reducing operations and maintenance costs.

[0033] According to a second aspect of the present invention, an integration and exception handling apparatus for a client printing service component is also provided, applied to a web application system, the apparatus comprising at least: Permission verification module: used to obtain the permission identifier of the current terminal user and determine whether it has the permission to call the target printing component; Layered loading module: Used to execute the layered strategy of "lightweight service detection first, heavyweight script loading as a fallback", including prioritizing service availability detection through at least one first communication port, and automatically loading the core script through at least one second communication port after the detection fails. State management module: Used to maintain a global state object that represents the script loading state; Asynchronous Instantiation Module: This module encapsulates the logic for obtaining instances of printing components into asynchronous programming objects. By polling the global state object and controlling timeouts, it returns functional instances or fault guidance information in a non-blocking manner.

[0034] Therefore, through the coordinated operation of the aforementioned modules, the device achieves full lifecycle management of the client printing service components, specifically: The permission verification module checks the terminal user's permission identifier at the loading entry point. Only authorized users can trigger the subsequent loading process, effectively avoiding the invalid resource consumption of unauthorized terminals. Invalid loading requests are reduced by more than 95%, and terminal memory usage is reduced by 20%-30%. The layered loading module adopts a strategy of "lightweight service detection first, heavyweight script loading as a backup". It prioritizes service availability detection through the first communication port (such as WebSocket on port 8000 / 18000). If the detection fails, it automatically switches to the second communication port (such as HTTP / HTTPS on port 8000 / 18000 / 8443) to dynamically load the core script. This mechanism increases the component loading success rate from about 70% to over 99.9%, and the failover response time is less than 500 milliseconds. The state management module maintains a global state object and uniformly marks the script loading status (such as probing, loading, and completed), avoiding duplicate loading and misjudgment of status, reducing the component call exception rate from 25% to 0. The asynchronous instantiation module encapsulates instance acquisition logic into asynchronous programming objects such as Promise. By polling a global state object and using timeout control (e.g., polling every 50ms and timeout for 10 seconds), it returns functional instances or fault guidance information in a non-blocking manner. This module is perfectly compatible with the asynchronous paradigm of modern front-end frameworks such as Vue and React, reducing the amount of business layer code by more than 70% and improving development efficiency by 80%. This device comprehensively addresses the core pain points of client-side printing service component integration in existing technologies from four dimensions: access control, loading reliability, state consistency, and call compatibility.

[0035] In some embodiments, the device further includes: Environment adaptation module: used to parse user agent information before permission verification and determine whether the printing component needs to be loaded in the current terminal environment based on the compatibility rule set; Architecture parsing module: Used to parse terminal system information, identify its underlying architecture type, and provide the address of the matching component installation package accordingly.

[0036] Thus, through the coordinated operation of the aforementioned additional modules, the device's adaptability to the terminal environment and its deployment friendliness are further enhanced: Before permission verification, the environment adaptation module parses the user agent information and, based on a pre-defined set of compatibility rules (including differentiation between mobile and desktop devices, identification of mainstream browser versions such as Chrome / Firefox / Opera / Edge, and exemption for older versions of Internet Explorer that support native controls), accurately determines whether the printing component needs to be loaded in the current terminal environment. This module avoids executing invalid component loading processes in unnecessary or incompatible terminal environments, achieving 100% compatibility coverage across all terminal browser types in the hospital, fundamentally solving cross-browser compatibility issues.

[0037] The architecture analysis module automatically identifies the underlying operating system architecture type (including but not limited to x64, x86, ARM64, etc.) by parsing the terminal's system information (such as navigator.userAgent and navigator.platform), and dynamically returns the download address of the matching print component installation package based on the identification result. This module enables end users to download the installer that is completely compatible with their own system architecture with one click when components are missing or versions are incompatible, significantly increasing the installation success rate from about 60% in the previous technology to over 98%, and reducing the installation time to less than 2 minutes, completely solving the problem of installation failure caused by architecture version incompatibility.

[0038] The two modules mentioned above improve the device's closed-loop adaptive capability to the terminal environment from the two dimensions of "whether loading is required" and "how to install correctly after loading failure". Together with the permission verification module, the layered loading module, the state management module and the asynchronous instantiation module, they constitute a complete and robust integrated solution for client printing service components.

[0039] In some embodiments, the device further includes: Closed-loop operation and maintenance module: used to capture exceptions during asynchronous instantiation and component invocation, collect context information including terminal environment parameters and error types, and report the information to the server.

[0040] Therefore, a complete anomaly monitoring and traceable operation and maintenance system was built through the closed-loop operation and maintenance module, specifically: Exception capture and collection: This module can capture various exceptions generated during the asynchronous instantiation process and printing component instance calls in real time (including but not limited to loading timeout, component not installed, port connection failure, version verification failure, etc.), and automatically collect structured fault context information, which includes at least terminal environment parameters (such as browser type and version, operating system architecture, user agent string), global state object snapshot (such as loading state history, polling records) and error type code.

[0041] Remote reporting and tracing: The collected fault context information is reported to the backend server via asynchronous communication methods (such as navigator.sendBeacon, fetch, or XMLHttpRequest), forming a centralized fault log database. Maintenance personnel can filter, analyze, and perform root cause analysis based on the reported logs to quickly locate the cause of the problem (e.g., all terminals in a department are x86 architecture but x64 installation packages are installed, or port 8000 of a certain internal network segment is blocked by a firewall).

[0042] Improved Operation and Maintenance Efficiency: This module transforms fault diagnosis from the inefficient "user feedback - on-site reproduction - log retrieval" model to the efficient "automatic reporting - centralized analysis - remote location" model. Practical application shows that the average fault diagnosis time has been significantly reduced from approximately 20 minutes using existing technologies to less than 3 minutes, a reduction of 85%. This significantly lowers operation and maintenance costs and improves system serviceability and user satisfaction.

[0043] The closed-loop operation and maintenance module works in conjunction with modules such as permission verification, layered loading, and asynchronous instantiation to form a complete closed loop of "loading-calling-error-reporting-analysis", enabling the device of this invention to have enterprise-level production environment adaptability.

[0044] According to a third aspect of the present invention, an electronic device is also provided, including one or more processors and a memory, the memory storing one or more programs that, when executed by the processor, implement the above-described integration and exception handling method for a client printing service component.

[0045] According to a fourth aspect of the present invention, a computer-readable storage medium is also provided, on which a computer program is stored, which, when executed by a processor, implements the above-described method for integration and exception handling of a client printing service component.

[0046] The beneficial effects of this invention are: Compared with existing technologies, this invention achieves significant technical effects in multiple dimensions in the scenario of integrating client-side local printing service components into web application systems (especially medical information systems) through a series of interconnected and complementary technical means, including "permission verification and isolation mechanism," "WebSocket+HTTP layered loading strategy," "terminal architecture adaptive installation guidance," "Promise-based asynchronous encapsulation," and "closed-loop operation and maintenance reporting": (a) Loading strategy dimension: Improving success rate and robustness 1.1 Significantly improves component loading success rate This invention employs a layered loading strategy of "lightweight WebSocket pre-detection + HTTP multi-port script fallback," adapting to multiple network ports such as 8000 / 18000 / 8443, and automatically switching the loading address based on the page protocol (HTTP / HTTPS). This effectively solves loading failure problems in complex network environments, such as port congestion, network policy restrictions, and HTTPS mixed content blocking. Practical application shows that the component loading success rate of this invention is significantly improved from approximately 70% in existing technologies to over 99.9%.

[0047] 1.2 Achieving millisecond-level failover Through a multi-port racing loading and protocol adaptive switching mechanism, when the default port of the local printing service (e.g., 8000) changes or malfunctions, the system can automatically switch to a backup port (e.g., 18000) or a secure port (e.g., 8443) within milliseconds, ensuring uninterrupted printing functionality. The measured fault transfer response time is less than 500 milliseconds, fully guaranteeing the continuity requirements of medical printing services.

[0048] 1.3 Adaptation to all terminal browser environments Through a sophisticated browser user agent parsing algorithm, differentiated adaptations are performed for various terminals and browsers such as mobile devices, Edge, Chrome, Firefox, Opera, and different versions of IE, ensuring 100% compatibility with all terminal browser types in the hospital and fundamentally solving cross-browser compatibility issues.

[0049] (II) Permission and Resource Control Dimension: Precise Isolation and Efficient Management 2.1 Achieve precise permission filtering By adding an access control mechanism based on organization ID, user role, or department ID at the loading entry point, only authorized terminals can trigger the component loading process, while unauthorized terminals automatically switch to the browser's native printing solution. Practical application shows that this mechanism reduces invalid loading requests by over 95%, reduces terminal memory usage by 20%-30%, and significantly alleviates intranet load and terminal resource consumption.

[0050] 2.2 Implement unified loading status management By declaring and maintaining global state variables (such as loadState), the various stages of the script loading process (probing, loading, and completed) are uniformly marked and controlled, effectively avoiding problems such as duplicate loading and misjudgment of state. In practical applications, the component call exception rate has dropped from 25% to 0, and the system stability and maintainability have been fundamentally improved.

[0051] (III) Installation and Adaptation Dimension: Improving Experience and Efficiency 3.1 Achieving Adaptive and Precise Installation Guidance By parsing end-user agent and platform information, the system automatically identifies the underlying operating system architecture (x64 / x86) and dynamically returns the matching installation package download address. End-users such as healthcare workers can download the correct installer with a single click without needing to identify the system version themselves. Real-world applications show that the installation success rate has significantly increased from 60% to over 98%, and the installation time has been reduced to less than 2 minutes, greatly lowering the operational threshold and ensuring the efficient implementation of printing services.

[0052] 3.2 Achieve seamless compatibility with modern front-end frameworks By encapsulating the process of obtaining instances of printing components such as Clodop into Promise objects, fully asynchronous calls are achieved, perfectly adapting to the asynchronous data-driven paradigm of modern front-end frameworks such as Vue and React. Business layer call code is simplified from cumbersome state checks and nested callbacks to a concise async / await pattern. Practical applications show that the amount of business layer code is reduced by more than 70%, development efficiency is improved by 80%, and the historical problem of "controls not ready" is completely solved.

[0053] (iv) Compatibility and maintainability dimension: reducing operation and maintenance costs 4.1 Implementing structured exception handling and closed-loop operation and maintenance This invention establishes a complete anomaly monitoring and reporting system that can automatically identify fault types such as "loading timeout," "component not installed," and "port connection failure," and collect contextual information such as browser version, terminal architecture, and loading status, reporting it to the backend server via asynchronous communication. Maintenance personnel can quickly filter and locate the root cause of problems based on the reported logs. Practical application shows that fault diagnosis time has been significantly reduced from an average of 20 minutes to less than 3 minutes, resulting in a significant reduction in maintenance costs.

[0054] In summary, this invention discloses a method, apparatus, device, and storage medium for integrating and handling exceptions in a client-side printing service component. The method includes: obtaining user permission identifiers for permission verification; implementing a layered loading strategy of "lightweight service detection first, heavyweight script loading as a fallback," prioritizing service detection through a first communication port, and automatically loading the core script through a second communication port if detection fails; maintaining a global state object to mark the loading status; encapsulating instance acquisition as an asynchronous programming object, and returning instance or fault guidance information in a non-blocking manner through polling and timeout control. This invention solves the problems of low local printing service loading success rate, lack of permission control, difficult installation and adaptation, incompatibility with front-end frameworks, and lack of failover, increasing the loading success rate to over 99.9%, reducing invalid loading by over 95%, increasing the installation success rate to over 98%, and shortening fault diagnosis time to within 3 minutes. Attached Figure Description

[0055] Figure 1 This is an overall flowchart of a method for integrating and handling exceptions in a client-side printing service component, according to one embodiment of the present invention.

[0056] Figure 2 This is a schematic diagram of a layered loading strategy according to one embodiment of the present invention.

[0057] Figure 3 This is a timing diagram of asynchronous Promise acquisition and status polling according to one embodiment of the present invention.

[0058] Figure 4 This is a system framework diagram of an integration and exception handling device for a client printing service component according to one embodiment of the present invention.

[0059] Figure 5 This is a schematic diagram of an electronic device according to one embodiment of the present invention. Detailed Implementation

[0060] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings and embodiments. It should be understood that the specific embodiments described herein are merely illustrative and not intended to limit the invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without inventive effort are within the scope of protection of this invention.

[0061] This invention belongs to the fields of medical information technology and web printing technology, specifically relating to a method, apparatus, electronic device and storage medium for integrating and handling anomalies of client printing service components.

[0062] Reference Figure 1-3As shown, the present invention provides a method for integration and exception handling of client printing service components.

[0063] This method can be executed by an electronic device, which can be implemented by software and / or hardware. The method is applied to a web application system and includes the following steps: Permission verification steps: Obtain the permission identifier of the current terminal user and determine whether it has the permission to call the target printing component. If it does not have the permission, terminate the integration process or switch to the alternative printing solution. Layered loading steps: The layered strategy of "lightweight service detection first, heavyweight script loading as a fallback" is implemented. The layered strategy includes: prioritizing the establishment of a lightweight connection with the local printing service through at least one first communication port for availability detection; if the detection fails, it automatically switches to script loading mode and dynamically loads the core script file of the printing component through at least one second communication port. State management steps: Maintain a global state object to at least represent the loading state of the core script files; Asynchronous instantiation steps: The logic for obtaining the instance of the printing component is encapsulated into an asynchronous programming object. The asynchronous programming object obtains and returns the functional instance of the printing component in a non-blocking manner by polling the global state object and using timeout control, or returns an error object containing fault guidance information when it fails.

[0064] As a preferred option, the permission identifier in the permission verification step can be, but is not limited to: institution ID (applicable to group hospitals or multi-campus scenarios), user role ID (such as doctor, nurse, administrator), department ID (such as radiology department, medical records department), function permission code, or user group ID; the specific implementation of terminating the integration process can be to directly return false or an empty function, and switching to the alternative printing solution can be to call window.print() or load a lightweight pure front-end printing library.

[0065] Preferably, lightweight connections in the layered loading step include, but are not limited to: WebSocket connections, HTTP GET requests (e.g., sending probe packets to http: / / localhost:8000), Ping commands, or custom TCP socket probes; typical examples of the first communication port include: port 8000 (CLodop's default service port), port 18000 (CLodop's alternate port), and port 8011 (JSPrintManager's default port); typical examples of the second communication port include: port 8000 (HTTP script), port 18000 (HTTP alternate script), and port 8443 (HTTPS secure script); core script files include, but are not limited to: CLodopfuncs.js, JSPrintManager.js, or any JavaScript library file used to initialize the printing component API.

[0066] Preferably, the global state object in the state management step can be a string variable or an enumeration type mounted on the window object, and its state values ​​include at least: null (not started), 'loading_ws' (WebSocket probing), 'loading_http' (HTTP script loading), and 'complete' (loading complete). It can also extend the state to include 'failed' to support more granular exception handling.

[0067] Preferably, the asynchronous programming objects used in the asynchronous instantiation step include, but are not limited to: JavaScriptPromise objects, jQuery Deferred objects, asynchronous wrappers based on callback functions, or RxJS Observables. A typical implementation of polling is the `setInterval` function, with an interval of 50 milliseconds; a typical implementation of timeout control is the `setTimeout` function, with a timeout of 10 seconds. Error guidance information includes: error type strings (such as "load timed out," "component not installed," "port connection failed"), adaptive installation package download address, help documentation link, or customer service contact information.

[0068] Preferably, the lightweight service probing in the layered loading step further includes: The racing mode is used to initiate connection requests to multiple different communication ports in parallel. The first successfully established connection is considered a valid probe result, and other connection attempts are terminated. If all connection attempts on all ports fail, the service detection is deemed to have failed, triggering a fallback script loading process.

[0069] As a further preferred option, the specific implementation of the race mode could be Promise.race([ws1, ws2,...]); multiple different communication ports including ports 8000 and 18000; terminating other connection attempts could include calling the close() method of the WebSocket object or ignoring subsequent callbacks.

[0070] As a preferred embodiment, the script loading mode in the layered loading step further includes: Try loading the script via the default communication port first; If the process fails, the port will be automatically adapted based on the network protocol type of the current web page: if the page uses a secure protocol, the port corresponding to the secure protocol will be switched to for loading; if the page uses a non-secure protocol, the port corresponding to the non-secure protocol will be switched to for loading.

[0071] As a preferred method, the fault guidance information in the asynchronous instantiation step is generated through the following sub-steps: Analyze the system information of the current terminal to identify its underlying hardware or operating system architecture type; Based on the identified architecture type, retrieve and return the installation package address of the printing component that matches the architecture from the preset mapping relationship.

[0072] As a further preferred option, system information includes, but is not limited to: the navigator.userAgent string, the navigator.platform property, and OS information obtained through browser plugins; architecture types include: x64 (also known as amd64, x86-64), x86 (also known as ia32), ARM64 (such as Apple M series chips), etc.; preset mapping relationship example: if the architecture is x64, then CLodop_Setup.exe or JSPrintManager-Setup-x64.exe is returned; if it is x86, then CLodop_Setup32.exe or JSPrintManager-Setup-x86.exe is returned; if it is ARM64, then the corresponding ARM version installation package is returned.

[0073] Preferably, a terminal environment adaptation step is included before the permission verification step: Parse the user agent information of the current terminal and determine whether the printing component needs to be loaded in the current environment based on the preset compatibility rule set; The compatibility rule set includes at least: identification of specific browser brands and versions, differentiation between mobile and desktop versions, and exemption determination for older browser versions that support native controls.

[0074] As a further preferred option, specific examples of the compatibility rule set include: Mobile device (UA matching / mobile / i) → needs to be loaded (or determined based on actual capabilities); Edge browser (UA matching / edge / i) → needs to be loaded; Firefox browser, version 41 or higher → needs to be loaded; Chrome browser, version 41 or higher → needs to be loaded; Opera browser, version 32 or higher → needs to be loaded; 64-bit non-IE browsers → need to load; Internet Explorer (UA matches / msie|trident / i) and version <11 → No need to load (ActiveX controls can be used). Other cases → need to be loaded by default.

[0075] Preferably, during the asynchronous instantiation step, the asynchronous programming object is also used internally for: After successfully obtaining the printing component instance, call its built-in version or status verification interface, and cache the instance in the global scope after the verification is successful. When an instance fails to be retrieved or an operation times out, the error object thrown contains the error type, fault guidance information, and preset fault troubleshooting context data.

[0076] As a preferred approach, the integration and troubleshooting methods for client-side printing service components also include closed-loop operation and maintenance steps: Capture asynchronous instantiation steps and print exceptions during component instance invocation; Collect fault context information, which includes at least one of terminal environment parameters, global state object snapshot, and error type; The collected information is reported to the server through the backend interface to form a traceable fault record.

[0077] As a further preferred option, the fault context information includes, but is not limited to: user agent string, terminal operating system architecture, global state object value, error message, occurrence timestamp, and current page URL; the backend interface can use asynchronous communication technologies such as XMLHttpRequest, fetch, and navigator.sendBeacon.

[0078] Reference Figure 4 As shown, the present invention also provides an integration and exception handling device for a client printing service component.

[0079] The device includes a permission verification module, a hierarchical loading module, a state management module, an asynchronous instantiation module, an environment adaptation module, an architecture parsing module, and a closed-loop operation and maintenance module. These modules can also be referred to as units, which are a series of computer program segments that can be executed by the processor of an electronic device and perform a fixed function, stored in the memory of the electronic device.

[0080] In this embodiment, the functions of each module / unit are as follows: Permission verification module: used to obtain the permission identifier of the current terminal user and determine whether it has the permission to call the target printing component; Layered loading module: Used to execute the layered strategy of "lightweight service detection first, heavyweight script loading as a fallback", including prioritizing service availability detection through at least one first communication port, and automatically loading the core script through at least one second communication port after the detection fails. State management module: Used to maintain a global state object that represents the script loading state; Asynchronous Instantiation Module: This module encapsulates the logic for obtaining instances of printing components into asynchronous programming objects. By polling the global state object and controlling timeouts, it returns functional instances or fault guidance information in a non-blocking manner.

[0081] Environment adaptation module: used to parse user agent information before permission verification and determine whether the printing component needs to be loaded in the current terminal environment based on the compatibility rule set; Architecture parsing module: Used to parse terminal system information, identify its underlying architecture type, and provide the address of the matching component installation package accordingly.

[0082] Closed-loop operation and maintenance module: used to capture exceptions during asynchronous instantiation and component invocation, collect context information including terminal environment parameters and error types, and report the information to the server.

[0083] like Figure 4As shown, this demonstrates the system framework for running this device. This framework comprises three main parts: a front-end application layer, an integration and exception handling mechanism for client-side printing service components, and an external environment. The front-end application layer contains business components (such as Vue / React components) used to initiate print requests. The external environment includes a local printing service (such as Clodop or JSPrintManager), a back-end log server (receiving fault reports), and an installation package server (providing x64 / x86 version installation packages for download). The business components call the permission verification module. After successful verification, the printing component instance is obtained through the collaborative efforts of modules such as environment adaptation, layered loading, state management, and asynchronous instantiation. Finally, the instance or fault guidance information is returned. Simultaneously, exception information is reported to the log server via the closed-loop operation and maintenance module, and the installation guidance request is directed from the architecture resolution module to the installation package server.

[0084] Reference Figure 5 As shown, the present invention also provides an electronic device capable of running the above-described integration and exception handling method for client printing service components.

[0085] The electronic device 1 includes, but is not limited to, a memory 11, a processor 12, a display 13, and a network interface 14. The electronic device 1 connects to a network via the network interface 14 to acquire raw data. The network can be an intranet, the Internet, a Global System for Mobile Communication (GSM), Wideband Code Division Multiple Access (WCDMA), a 4G network, a 5G network, Bluetooth, WiFi, a voice communication network, or other wireless or wired networks.

[0086] The memory 11 includes at least one type of readable storage medium, including flash memory, hard disk, multimedia card, card-type memory (e.g., SD or DX memory), random access memory (RAM), static random access memory (SRAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), programmable read-only memory (PROM), magnetic memory, disk, optical disk, etc.

[0087] Preferably, the memory 11 can be an internal storage unit of the electronic device 1, such as a hard disk or RAM of the electronic device 1. In other embodiments, the memory 11 can also be an external storage device of the electronic device 1, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD) card, flash card, etc., equipped with the electronic device 1. Of course, the memory 11 can also include both internal storage units and external storage devices of the electronic device 1.

[0088] In this embodiment, the memory 11 is typically used to store the operating system and various application software installed on the electronic device 1, such as the program code for the integration of the client printing service component and the exception handling program 10. In addition, the memory 11 can also be used to temporarily store various types of data that have been output or will be output.

[0089] The processor 12 may preferably be a central processing unit (CPU), controller, microcontroller, microprocessor, or other data processing chip. The processor 12 is typically used to control the overall operation of the electronic device 1, such as performing data interaction or communication-related control and processing. In this embodiment, the processor 12 is used to run program code stored in the memory 11 or process data, for example, to run program code for the integration and exception handling program 10 of the client printing service component.

[0090] The display 13 can be referred to as a display screen or display unit. Preferably, the display 13 can be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an organic light-emitting diode (OLED) touchscreen, etc. The display 13 is used to display information processed in the electronic device 1 and to display a visual working interface, such as displaying the results of data statistics.

[0091] The network interface 14 may optionally include a standard wired interface or a wireless interface (such as a WIFI interface), which is typically used to establish a communication connection between electronic device 1 and other electronic devices.

[0092] Figure 5 Only an electronic device 1 with components 11-14 and an integration and exception handling procedure 10 for the client printing service component is shown. However, it should be understood that it is not required to implement all of the components shown, and more or fewer components may be implemented instead.

[0093] Optionally, the electronic device 1 may further include a user interface, which may include a display, an input unit such as a keyboard, and optionally, a standard wired interface or a wireless interface. Preferably, the display may be an LED display, a liquid crystal display, a touch-sensitive liquid crystal display, or an organic light-emitting diode (OLED) touchscreen. The display may also be appropriately referred to as a screen or display unit, used to display information processed in the electronic device 1 and to display a visual user interface.

[0094] The electronic device 1 may also include radio frequency (RF) circuits, sensors, and audio circuits, etc., which will not be described in detail here.

[0095] In the above embodiments, when the processor 12 executes the integration and exception handling program 10 for the client printing service component stored in the memory 11, it can perform the following steps: Permission verification steps: Obtain the permission identifier of the current terminal user and determine whether it has the permission to call the target printing component. If it does not have the permission, terminate the integration process or switch to the alternative printing solution. Layered loading steps: The layered strategy of "lightweight service detection first, heavyweight script loading as a fallback" is implemented. The layered strategy includes: prioritizing the establishment of a lightweight connection with the local printing service through at least one first communication port for availability detection; if the detection fails, it automatically switches to script loading mode and dynamically loads the core script file of the printing component through at least one second communication port. State management steps: Maintain a global state object to at least represent the loading state of the core script files; Asynchronous instantiation steps: The logic for obtaining the instance of the printing component is encapsulated into an asynchronous programming object. The asynchronous programming object obtains and returns the functional instance of the printing component in a non-blocking manner by polling the global state object and using timeout control, or returns an error object containing fault guidance information when it fails.

[0096] The storage device can be the memory 11 of the electronic device 1, or it can be other storage devices that are communicatively connected to the electronic device 1.

[0097] For a detailed explanation of the above steps, please refer to the above. Figure 4 Functional block diagram of an embodiment of an integration and exception handling apparatus for a client-side printing service component and Figure 1-3 A flowchart illustrating an embodiment of the integration and exception handling method for client-side printing service components.

[0098] Furthermore, this invention also proposes a computer-readable storage medium, which can be non-volatile or volatile. This computer-readable storage medium can be any one or any combination of several of the following: hard disk, multimedia card, SD card, flash memory card, SMC, read-only memory (ROM), erasable programmable read-only memory (EPROM), portable compact disc read-only memory (CD-ROM), USB memory, etc. The computer-readable storage medium includes a data storage area and a program storage area. The data storage area stores data created based on the use of blockchain nodes, and the program storage area stores an integration and exception handling program 10 for the client printing service component. When executed by the processor, the integration and exception handling program 10 for the client printing service component performs the following operations: Permission verification steps: Obtain the permission identifier of the current terminal user and determine whether it has the permission to call the target printing component. If it does not have the permission, terminate the integration process or switch to the alternative printing solution. Layered loading steps: The layered strategy of "lightweight service detection first, heavyweight script loading as a fallback" is implemented. The layered strategy includes: prioritizing the establishment of a lightweight connection with the local printing service through at least one first communication port for availability detection; if the detection fails, it automatically switches to script loading mode and dynamically loads the core script file of the printing component through at least one second communication port. State management steps: Maintain a global state object to at least represent the loading state of the core script files; Asynchronous instantiation steps: The logic for obtaining the instance of the printing component is encapsulated into an asynchronous programming object. The asynchronous programming object obtains and returns the functional instance of the printing component in a non-blocking manner by polling the global state object and using timeout control, or returns an error object containing fault guidance information when it fails.

[0099] The specific implementation of the computer-readable storage medium of the present invention is largely the same as the specific implementation of the above-described method for integrating and handling exceptions of client printing service components, and will not be repeated here.

[0100] To better explain the technical solution of the present invention, the present invention also provides the following specific embodiments: Example 1: Integration of VTE Prevention and Control System Based on CLodop This embodiment uses the integration of the CLodop printing control into a VTE (venous thromboembolism) prevention and control system as an example to illustrate the specific implementation of the present invention in detail. It should be noted that this specific application scenario is merely a preferred example and does not constitute a limitation on the scope of protection of the present invention.

[0101] Reference Figure 1-3 The method includes the following steps: Step S101: Initialize global configuration and state: Define core configuration variables on the front-end global object (e.g., window): MAIN_JS='CLodopfuncs.js'; loadState = null; / / Optional values: 'loading_ws', 'loading_http', 'complete' cachedLodop=null; WS_URLS=['ws: / / 127.0.0.1:8000', 'ws: / / 127.0.0.1:18000']; SCRIPT_URLS=['http: / / 127.0.0.1:8000 / CLodopfuncs.js','http: / / 127.0.0.1:18000 / CLodopfuncs.js','https: / / 127.0.0.1:8443 / CLodopfuncs.js'].

[0102] Step S102: Permission verification: Get the organization ID of the currently logged-in user (e.g., read from Vuex or localStorage), and check if it is equal to the preset target organization ID (e.g., 1016). If not, call fallbackToBrowserPrint() and terminate.

[0103] Step S103: Terminal Environment Adaptation: The `needCLodop()` function is called to parse `navigator.userAgent`, and the determination rules are as follows: javascript function needCLodop() { let ua = navigator.userAgent; if ( / mobile / i.test(ua) || / edge / i.test(ua)) return true; let ffVer = ua.match( / firefox\ / (\d+) / i); if (ffVer&&parseInt(ffVer[1])>= 41) return true; let chromeVer = ua.match( / chrome\ / (\d+) / i); if(chromeVer&&! / edge / i.test(ua)&&parseInt(chromeVer[1])>= 41) returntrue; let operaVer = ua.match( / opr\ / (\d+) / i); if (operaVer&&parseInt(operaVer[1])>= 32) return true; if ( / msie|trident / i.test(ua)) return false; / / IE uses ActiveX return true; / / Default is required } Step S104: Lightweight service detection (race mode): javascript function probeWebSocket() { let p1 = new Promise((resolve, reject) =>{ / * connect ws: / / ...:8000 * / }); let p2 = new Promise((resolve, reject) =>{ / * connect ws: / / ...:18000 * / }); return Promise.race([p1, p2]).then(ws =>{ ws.close(); return true;}).catch(() =>false); } If the probe is successful, mark loadState as 'complete' (a successful probe does not necessarily mean that the script needs to be loaded, but the service can be considered available and ready to obtain the instance directly); if the probe fails, proceed to step S105.

[0104] Step S105: HTTP script fallback loading: Call loadScriptsFallback(); prioritize loading the script on port 8000, and if it fails, determine the port based on location.protocol: if it is https, load the HTTPS script on port 8443, otherwise load the HTTP script on port 18000; after the script is loaded successfully, set loadState to 'complete' in the onload callback.

[0105] Step S106: Asynchronous instantiation (Promise wrapper): Provides the getLodop() function, which returns a Promise; internally polls loadState with a timeout of 10 seconds and an interval of 50ms; on success, it retrieves window.getCLodop() or uses a cached instance and performs version verification; on failure, it calls getWinArch() to identify the architecture and returns an error with the download address.

[0106] Step S107: Business layer invocation and exception reporting: In Vue components: javascript async printDocument(data) { try { const lodop = await getLodop(); / / Execute print... } catch (err) { this.$message.error(err.message); reportException({ type: err.type, arch: err.arch, ua:navigator.userAgent}); } } Example 2: An Alternative Implementation Based on JSPrintManager This embodiment demonstrates the application of the framework of the present invention to another local printing plugin—JSPrintManager (JSPM).

[0107] Step S201: Configure Differentiation: Core script: JSPrintManager.js; WebSocket probe port: ws: / / localhost:8011 (JSPM default port); Script loading address: http: / / localhost:8011 / JSPrintManager.js; Installation packages: JSPrintManager-Setup-x64.exe (x64) and JSPrintManager-Setup-x86.exe (x86); Step S202: Obtain the differences from the instance: The original window.getCLodop() has been replaced with a window.JSPrintManager object; During instantiation, you need to call JSPrintManager.install() or a similar initialization method; The code logic for all other steps (permission verification, environment adaptation, layered loading, state management, asynchronous encapsulation, architecture detection, and exception reporting) completely reuses the framework of Example 1.

[0108] This demonstrates the universality of the invention, and any local printing component with a similar architecture can be easily adapted and integrated.

[0109] Example 3: Generalized Implementation of Permission Identifiers Based on Example 1, the permission identifier is replaced from "Organization ID" to a combination of "User Role" and "Department ID". For example: javascript const userRole = getCurrentUserRole(); / / 'doctor', 'nurse', 'admin' const deptId = getCurrentDeptId(); if ((userRole === 'doctor' || userRole === 'nurse')&&deptId === 'RADIOLOGY') { / / Allow loading CLodop } else { fallbackToBrowserPrint(); } This variant implements more flexible access control.

[0110] Example 4: Variation of the detection method – HTTP GET detection WebSocket may not be supported in some older browsers. In this case, you can replace the lightweight probing method with an HTTP HEAD or GET request. For example, send a simple fetch request to http: / / localhost:8000. If the response status code is 200 or 304, the service is considered available.

[0111] Example 5: A Variation of Asynchronous Programming Objects—Callback Function Encapsulation For older projects that do not use Promise, instance retrieval can be encapsulated in an asynchronous pattern based on callback functions: javascript function getLodopCallback(successCallback, failCallback) { const timer = setInterval(() =>{ if (window.loadState === 'complete') { clearInterval(timer); const lodop = window.getCLodop(); if (lodop&&lodop.VERSION) successCallback(lodop); else failCallback('Component not installed'); } }, 50); setTimeout(() =>{ clearInterval(timer); failCallback('timeout');},10000); } This variant also implements non-blocking retrieval, representing another way to implement asynchronous programming objects.

[0112] It should be noted that the sequence numbers of the above embodiments of the present invention are merely for descriptive purposes and do not represent the superiority or inferiority of the embodiments. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, apparatus, article, or method 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, apparatus, article, or method. Without further limitations, an element defined by the phrase "comprising one..." does not exclude the presence of other identical elements in the process, apparatus, article, or method that includes that element.

[0113] Through the above description of the embodiments, those skilled in the art can clearly understand that the methods of the above embodiments can be implemented by means of software plus necessary general-purpose hardware platforms. Of course, they can also be implemented by hardware, but in many cases the former is a better implementation method. Based on this understanding, the technical solution of the present invention, or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product is stored in a storage medium (such as ROM / RAM, magnetic disk, optical disk) as described above, and includes several instructions to cause a terminal device (which may be a mobile phone, computer, electronic device, or network device, etc.) to execute the methods described in the various embodiments of the present invention.

[0114] The above are merely preferred embodiments of the present invention and do not limit the scope of the patent. Any equivalent structural or procedural transformations made based on the description and drawings of the present invention, or direct or indirect applications in other related technical fields, are similarly included within the scope of patent protection of the present invention.

Claims

1. A method for integrating and handling exceptions in a client-side printing service component, characterized in that, When applied to web application systems, the following steps are included: Permission verification steps: Obtain the permission identifier of the current terminal user and determine whether it has the permission to call the target printing component. If it does not have the permission, terminate the integration process or switch to the alternative printing solution. Layered loading steps: Execute a layered strategy of "lightweight service detection first, heavyweight script loading as a fallback". The layered strategy includes: prioritizing the establishment of a lightweight connection with the local printing service through at least one first communication port for availability detection; if the detection fails, automatically switch to script loading mode and dynamically load the core script file of the printing component through at least one second communication port. State management steps: Maintain a global state object to at least represent the loading state of the core script file; Asynchronous instantiation steps: The logic for obtaining the instance of the printing component is encapsulated into an asynchronous programming object. The asynchronous programming object obtains and returns the functional instance of the printing component in a non-blocking manner by polling the global state object and cooperating with timeout control, or returns an error object containing fault guidance information when it fails.

2. The integration and exception handling method for client printing service components according to claim 1, characterized in that, The lightweight service detection in the layered loading step further includes: The racing mode is used to initiate connection requests to multiple different communication ports in parallel. The first successfully established connection is considered a valid probe result, and other connection attempts are terminated. If all connection attempts on all ports fail, the service detection is deemed to have failed, triggering a fallback script loading process.

3. The integration and exception handling method for client printing service components according to claim 1, characterized in that, The script loading mode in the layered loading step further includes: Try loading the script via the default communication port first; If the process fails, the port will be automatically adapted based on the network protocol type of the current web page: if the page uses a secure protocol, the port corresponding to the secure protocol will be switched to for loading; if the page uses a non-secure protocol, the port corresponding to the non-secure protocol will be switched to for loading.

4. The integration and exception handling method for client printing service components according to claim 1, characterized in that, The fault guidance information in the asynchronous instantiation step is generated through the following sub-steps: Analyze the system information of the current terminal to identify its underlying hardware or operating system architecture type; Based on the identified architecture type, retrieve and return the installation package address of the printing component that matches the architecture from the preset mapping relationship.

5. The integration and exception handling method for a client-side printing service component according to any one of claims 1-4, characterized in that, Before the permission verification step, there is also a terminal environment adaptation step: The user agent information of the current terminal is parsed, and the printing component is determined according to the preset compatibility rule set. The compatibility rule set includes at least: identification of specific browser brands and versions, differentiation between mobile and desktop devices, and exemption determination for older browser versions that support native controls.

6. The integration and exception handling method for a client printing service component according to any one of claims 1-4, characterized in that, In the asynchronous instantiation step, the asynchronous programming object is also internally used for: After successfully obtaining the printing component instance, call its built-in version or status verification interface, and cache the instance in the global scope after the verification is successful. When an instance fails to be acquired or an operation times out, the error object thrown contains the error type, the fault guidance information, and preset fault troubleshooting context data.

7. The integration and exception handling method for a client-side printing service component according to claim 6, characterized in that, It also includes closed-loop operation and maintenance steps: Capture exceptions during the asynchronous instantiation step and the process of calling the printing component instance; Collect fault context information, which includes at least one of terminal environment parameters, global state object snapshot, and error type; The collected information is reported to the server through the backend interface to form a traceable fault record.

8. An integration and exception handling apparatus for a client-side printing service component, characterized in that, Applied to web application systems, including: Permission verification module: used to obtain the permission identifier of the current terminal user and determine whether it has the permission to call the target printing component; Layered loading module: Used to execute the layered strategy of "lightweight service detection first, heavyweight script loading as a fallback", including prioritizing service availability detection through at least one first communication port, and automatically loading the core script through at least one second communication port after the detection fails. State management module: Used to maintain a global state object that represents the script loading state; Asynchronous instantiation module: This module encapsulates the logic for obtaining instances of the printing component into an asynchronous programming object. By polling the global state object and controlling timeouts, it returns functional instances or fault guidance information in a non-blocking manner.

9. The integration and exception handling apparatus for a client printing service component according to claim 8, characterized in that, Also includes: Environment adaptation module: used to parse user agent information before permission verification and determine whether the printing component needs to be loaded in the current terminal environment based on the compatibility rule set; Architecture parsing module: Used to parse terminal system information, identify its underlying architecture type, and provide the address of the matching component installation package accordingly.

10. The integration and exception handling apparatus for a client printing service component according to claim 8, characterized in that, Also includes: Closed-loop operation and maintenance module: used to capture exceptions during asynchronous instantiation and component invocation, collect context information including terminal environment parameters and error types, and report the information to the server.

Images