A Card Reader Plug-in Compatibility Method and System

Abstract

This invention discloses a plug-in compatibility method and system for card readers, specifically relating to the field of card reader access compatibility technology. It addresses the problems of needing separate adaptations for each system, inconsistent interface styles, poor card reader compatibility, and high maintenance and modification costs when multiple brands, models, and communication methods of card readers exist simultaneously in multi-portal business systems. By setting up a card reader access layer outside the business systems, a unified standard interface for card reader control and card data structure are established. A configuration repository and plug-in registry are used to centrally manage and adapt plug-ins according to card reader type and operating environment. This allows each business system to initiate card reading requests only through the card reader access layer and complete plug-in selection and card information feedback based on the card reading request identifier. This decouples the card reader access logic from the business systems in multi-portal, multi-brand, and multi-model scenarios, reducing access and modification costs and improving card reader compatibility and reusability.

Description

Technical Field

[0001] This invention relates to the field of card reader access compatibility technology, specifically to a card reader plug-in compatibility method and system. Background Technology

[0002] In existing business outlets and government / enterprise service scenarios, business systems such as sales portals, government / enterprise portals, billing systems, and outsourced personnel management systems generally require card reading functions for various media, including ID cards, employee badges, and access cards. Current technology typically involves each business system separately interfacing with a specific card reader, directly integrating the manufacturer's drivers and communication libraries within the system, with each system defining its own card reading interface, data format, and error return. As the number of card reader brands, models, and access methods increases, multiple manufacturers' devices and various terminal operating environments often coexist in the same location, leading to a situation where the card reading logic within each business system exhibits multiple sets of interfaces and fragmented field definitions.

[0003] Under the aforementioned model, on the one hand, there is a lack of a unified standard interface for card reader control and a unified card data structure. Inconsistencies in field names, field combinations, and error code meanings for the same card can easily arise across different systems, making it difficult for maintenance personnel to establish a unified troubleshooting approach. On the other hand, there is a lack of a centralized management mechanism for card reader types and terminal operating environment attributes. When introducing new card reader models or upgrading terminal operating systems and browser kernels, each business system needs to modify its own card reader integration code, resulting in a large workload, high change risks, and potential issues such as some systems being unable to read cards or others misjudging card status. Furthermore, existing solutions often use a fixed binding to a specific vendor's driver, lacking the ability to switch between plug-in versions based on card reader request status and to record unified errors. When communication anomalies or card reader failures occur, fault isolation and compatibility recovery cannot be completed within the same access layer.

[0004] In summary, existing technologies generally suffer from a lack of a unified card reader access layer and plug-in adaptation management mechanism in scenarios where multiple business systems share multiple types of card readers. This manifests in inconsistent card reader control interfaces, inconsistent card data structures, inconsistent error code definitions, and the need to modify each business system separately when the terminal environment and equipment change. This leads to complex card reader access, insufficient compatibility, and high maintenance costs. A technical solution is needed that establishes an independent access layer between the business system and the card reader, uniformly manages the card reader control interface, card data structure, and error marking, and centrally adapts and switches based on the card reader type and operating environment attributes to solve the aforementioned unified access and compatibility control problems. Summary of the Invention

[0005] To address the shortcomings of existing technologies, this invention provides a plug-in compatible method and system for card readers, thereby resolving the problems mentioned in the background section.

[0006] To achieve the above objectives, the present invention provides the following technical solution: a card reader plug-in compatibility method, comprising: S1. Set up the card reader access layer, define the standard interface for card reader control, and unify the card data structure and error codes; S2. Build adapter plugins for various card readers. The plugins encapsulate the underlying communication logic and implement standard interfaces, while recording the card reader type and operating environment attributes. S3. Set up a plugin directory in the card reader access layer, scan the plugin directory to obtain attributes, and build a plugin registry and load plugin entities according to the card reader type and runtime environment attributes. S4. When the business system issues a card reading request, the card reading access layer parses the terminal environment parameters and the target card reader identifier, retrieves candidate plugins according to the plugin registry, and selects the target plugin according to priority. S5. The card reader access layer calls the target plugin to perform device initialization and card detection, performs card reading operations to obtain card information and encapsulates it into a unified card data object and returns it to the business system. S6. If a communication error occurs for a preset number of consecutive times or a card reading failure occurs during the call process, the card reading access layer selects a backup plugin based on the plugin registry and re-executes the initialization and card reading operation, and records the plugin selection result and error information.

[0007] Furthermore, S1 includes: The card reader access layer sets up standard interfaces for card reader control, including device initialization, device detection, card detection, card reading, and resource release. The card reader access layer associates the card reader control standard interface definition, unified card data structure definition, and error code set with version numbers in the configuration repository; The unified card data structure includes card type identifier, card identification number, cardholder identifier, and issuing institution identifier; When the card reader access layer starts up, it loads the current version configuration from the configuration repository into memory. When processing card reading requests, it organizes card information according to a unified card data structure and marks card reading failures according to the error code set.

[0008] Furthermore, S2 includes: On the server where the card reader access layer is located, an adapter plugin is set up for the field card reader. The adapter plugin is stored as an independent software unit in the plugin directory and is loaded by the card reader access layer. The adapter plugins correspond to the card reader type and operating environment attributes registered in the configuration repository. The card reader type consists of the manufacturer's logo and the model logo. The runtime environment attributes include the terminal operating system type, browser kernel type, and site identifier.

[0009] Furthermore, the adapter plugin maintains the correspondence between the manufacturer protocol fields and the card type flag, card identification number, cardholder flag, and issuing institution flag in the unified card data structure locally; The content obtained from the card reader will be converted into a Uniform Card Data Object; The adapter plugin assigns fault codes to the manufacturer's return codes based on the set of error codes registered in the configuration repository.

[0010] Furthermore, S3 includes: The card reader access layer registers a list of plugin directories associated with the configuration version number in the configuration repository, and traverses the plugin directories to read the plugin description content at startup; The card reader access layer compares the manufacturer's mark, model mark and operating environment attributes in the plugin description with the values ​​registered in the configuration warehouse to eliminate mismatch records, and marks the compatible plugins with incomplete operating environment attributes as backup plugin candidates. The card reader access layer constructs a plugin registry based on the card reader type and operating environment attributes. Under each combination, the version number, priority, and monitoring status of the primary plugin entity and the backup plugin entity are registered.

[0011] Furthermore, S4 includes: When the card reader access layer receives a card reader request sent by the business system, it sequentially parses the terminal environment parameters, the target card reader identifier, and the card reader request identifier from the request message. Based on the terminal environment parameters and the target card reader identifier, candidate plugins are retrieved from the plugin registry snapshot corresponding to the configuration version number, and the target plugin is selected according to priority and duty status. The card reader request identifier and the target plugin identifier are written into the temporary session record. When the card reader request identifier appears repeatedly within a preset time window, the same target plugin is called based on the temporary session record.

[0012] Furthermore, S5 includes: The card reader access layer sequentially calls device initialization, card detection, and card reading operations based on the target plug-in identifier in the temporary session record, obtains card information from the card reader, generates a unified card data object according to the field mapping registered in the configuration repository, and returns it to the business system; The card reader access layer uses the card reader request identifier as the unique anchor point and retains only one copy of the unified card data object corresponding to the card reader request identifier in the local short-term cache for subsequent business access.

[0013] Furthermore, S6 includes: In the card reading link involving the target plugin, the card reader access layer counts the number of communication anomalies and the number of card reading failures based on the card reading request identifier; When the cumulative number of times reaches the preset number, a backup plugin is selected from entities with the same card reader type and runtime environment attributes but with a lower priority than the primary plugin, based on the plugin registry. Under the card reader request flag, re-execute device initialization, card detection, and card reading operations, and record the card reader request flag, terminal environment parameters, card reader type, primary plugin version number, backup plugin version number, error code, and time stamp in the log warehouse.

[0014] On the other hand, the present invention provides a card reader plug-in compatible system, comprising: The card reader access layer module is used to set up outside the business system and establish a connection with the business system. The card reader access layer defines the standard interface for card reader control, as well as the unified card data structure and error codes. The adapter plugin management module is used to register adapter plugins for various card readers, enabling the adapter plugins to encapsulate the underlying communication logic and implement the standard interface for card reader control. At the same time, it records the card reader type and operating environment attributes for the adapter plugins. The plugin registration module is used to set up a plugin directory in the card reader access layer, scan the adapter plugin files in the plugin directory to obtain the card reader type and runtime environment attributes, and build a plugin registry and load the plugin entity based on the card reader type and runtime environment attributes. The plugin selection module is used to parse terminal environment parameters and target card reader identifier when the business system issues a card reading request, and to search for candidate plugins according to the plugin registry and determine the target plugin according to priority. The card reading execution module is used to call the target plugin through the card reading access layer to perform device initialization and card detection, and to perform card reading operations to obtain card information, encapsulate it into a unified card data object, and return it to the business system; The fault handling module is used to detect communication anomalies and card reading failures after a preset number of consecutive calls during the call process. It then selects a backup plugin based on the plugin registry to re-execute the device initialization and card reading operation, and records the plugin selection result and anomaly information.

[0015] Compared with the prior art, the present invention has the following beneficial effects: 1. By setting up a card reader access layer outside the business system, a unified standard interface for card reader control and a unified card data structure are defined. Based on the configuration repository, the card reader type and runtime environment attributes are mapped to the adapter plugin. The plugin is centrally managed in the plugin registry according to version number and priority. Each business system initiates a card reading request only through the card reader access layer and completes the plugin selection and card information feedback according to the unique card reading request identifier. This decouples the card reading access logic from each business system in the field environment where multiple portals, brands, models and communication methods coexist. This significantly reduces the difficulty of card reading function access and the cost of transformation, and ensures that card reading behavior is consistent across different systems and has stronger compatibility and reusability.

[0016] 2. By unifying the mapping of manufacturer protocol fields and return codes within the adapter plugin, the card reading link introduces idempotent control for card detection and card reading results, local short-term caching, and deduplication strategies based on card reading request identifiers. When communication anomalies or card reading failures reach a preset number, the backup plugin is automatically switched according to the plugin registry. At the same time, the plugin selection results and fault information are written to the log warehouse and form an evidence chain with the version records in the configuration warehouse. This ensures that the continuity and stability of the card reading service can be maintained even under conditions of fluctuating field communication environment, browser kernel evolution, or card reader replacement. It also supports online evolution and problem tracing, improving the overall reliability and operational efficiency of the system. Attached Figure Description

[0017] Figure 1 This is a flowchart illustrating a card reader plug-in compatibility method according to the present invention; Figure 2 This is a schematic diagram of the structure of a card reader plug-in compatible system according to the present invention. Detailed Implementation

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

[0019] Example 1: A card reader plug-in compatibility method, comprising: S1. Set up the card reader access layer, define the standard interface for card reader control, as well as the unified card data structure and error codes. The specific implementation is as follows: In actual field deployment, the card reader access layer is installed in a controlled server on the side closest to the business system. The sales portal system, government and enterprise portal system, billing system, and outsourced personnel management system are collectively referred to as the business system. Each business system directs card reading requests to the card reader access layer through the internal network, and the card reader access layer interacts with the on-site card reader.

[0020] The card reader access layer refers to the intermediate control component located between the business system and the card reader. It carries the standard card reader control interface, unified card data structure, and error code set, and provides a unified calling method to the outside world. The standard card reader control interface refers to a set of pre-agreed operation control items in the card reader access layer, which fixedly includes five types of actions: device initialization, device detection, card detection, card reading command sequence, and resource release. Among them, device initialization refers to the action of opening the port, negotiating communication parameters, and performing security verification on the card reader on the target terminal; device detection refers to the action of confirming whether the card reader is properly connected and in a usable state within a limited time; card detection refers to the action of periodically checking whether there is media in the card slot or sensing area; card reading command sequence refers to the action of issuing multiple card reading control commands to the card reader in a unified order and summarizing and returning the content; and resource release refers to the action of closing the relevant channels and releasing the occupied resources after the card reading is completed.

[0021] The unified card data structure refers to the set of fields set up to carry card information. In the card reader access layer, it includes at least card type flag, card identifier, cardholder flag, issuing institution flag, and extended fields. Among them, the card type flag refers to the code used to distinguish the types of ID cards, work permits, access cards, etc.; the card identifier refers to the character sequence that can uniquely correspond to a card; the cardholder flag refers to the number or mark that can be associated with a natural person in the business system; the issuing institution flag refers to the code used to distinguish the issuing unit; and the extended fields refer to several additional fields reserved for subsequent scenarios. Each field adopts a fixed name and order, and the length is measured by the number of characters. The encoding method and length range are centrally registered in the configuration repository.

[0022] The configuration repository refers to the storage area that stores the standard interface definitions for card reader control, the unified card data structure definitions, and the error code set. Each set of definitions in the configuration repository is bound to a version number. Before changing the meaning of a field, adding or removing fields, or adjusting error codes, a new version must be generated first. The old version only retains query capabilities and no longer participates in new sessions. Error codes refer to a set of codes used to classify and mark card reader-related faults. Each code corresponds to a type of fault cause. After the card reader access layer obtains the error code set corresponding to the current version number from the configuration repository, it always uses this set for fault marking during operation.

[0023] Preferably, the error code can be set as a fixed-length unsigned integer code, and the code type can be set to several categories, such as device not connected, card not in place, communication result unreliable, parsing result non-compliant, plugin version mismatch, etc. Each type of code is accompanied by a text description in the configuration repository for maintenance personnel to locate problems online.

[0024] Preferably, the length of the card identifier in the unified card data structure can be set to a set of discrete values, such as sixteen to thirty-two characters, with the specific length determined by the document standard used on site; the cardholder identifier can be set to a character sequence with the same length as the customer identifier in the business system, so that the business system can directly use the card information for comparison.

[0025] During actual operation, the card reader access layer reads the current effective version number from the configuration repository during the startup phase. The standard interface definition for card reader control, the unified card data structure field definition, and the error code set for the corresponding version are loaded into memory at once, and an index is built in memory to reduce access latency in subsequent card reader calls. Before initiating a card reader request, the business system determines whether it needs complete card information or only the card identifier number based on its own scenario. However, regardless of the requesting side's requirements, the card reader access layer always organizes card information according to the unified card data structure and carries the corresponding error codes, ensuring that all business systems have a unified interpretation of card reader behavior under the same environment and version.

[0026] S2. Build adaptation plugins for various card readers. The plugins encapsulate the underlying communication logic and implement standard interfaces, while recording the card reader type and operating environment attributes. The specific implementation is as follows: After completing the card reader access layer setup, adapter plugins are built for each type of card reader based on the list of card readers already in operation on-site. An adapter plugin is an independent software unit deployed on the server hosting the card reader access layer. Each adapter plugin corresponds to a fixed set of card reader types and operating environment attributes, and is stored as a file in the plugin directory specified by the card reader access layer. It is loaded through the plugin management capabilities of the card reader access layer and is used to encapsulate the underlying communication logic between the business system and the specific card reader, and to implement the standard interface for card reader control.

[0027] The card reader type refers to a combination of identifiers that distinguishes the source and model of the card reader device. It consists of a manufacturer's mark and a model mark. The manufacturer's mark is a code assigned to the equipment supplier in the configuration repository, and the model mark is a code assigned to different models from the same manufacturer. The operating environment attribute refers to a set of terminal environment descriptions that affect the card reader's operation. It includes the terminal operating system type, browser kernel type, and site mark. The terminal operating system type refers to the type and version range of the operating system used by the terminal on site. The browser kernel type refers to the browser rendering kernel type on which the front-end page depends. The site mark is a code used to distinguish different physical sites or logical areas.

[0028] Manufacturer markings, model markings, and operating environment attributes are compiled by maintenance personnel based on the on-site equipment list, supply documents, and on-site survey records. The on-site equipment list refers to the equipment ledger that records the number, brand, and model of card readers installed in each business location. The supply documents refer to the product instruction materials provided by the supplier. The on-site survey records refer to the written records formed by verifying the placement location, access method, and usage environment of the terminals.

[0029] During the process, the naming rules for manufacturer names, model names, and site names were standardized, as were the units and value ranges. Duplicate names pointing to the same manufacturer or model were merged into a single identifier. Records lacking manufacturer, model, or site identifiers were supplemented by reviewing contract documents and confirming on-site before being written into the configuration repository. The configuration repository refers to a centralized configuration storage area maintained on the card reader access layer side. It is used to store the card reader control standard interface definition, unified card data structure definition, error code set, and the association between card reader type and operating environment attributes, and different configuration states are distinguished by version numbers.

[0030] Each adapter plugin internally implements all actions of the standard card reader control interface, sequentially completing device initialization, device detection, card detection, card reading command sequence, and resource release. When executing the above actions, it calls the underlying communication logic of the corresponding card reader type. The underlying communication logic refers to the set of instructions that completes command assembly and frame parsing based on the communication instructions and protocol fields disclosed by the manufacturer.

[0031] The manufacturer agreement field refers to the name, location, and encoding rules of the card information fields provided by the manufacturer in the product technical data. The adapter plugin maintains a one-to-one correspondence between the manufacturer agreement fields and the unified card data structure fields locally, and converts the original content obtained from the card reader into the card type identifier, card identification number, cardholder identifier, issuing institution identifier, and extended fields in the unified card data structure according to this correspondence.

[0032] Manufacturer return codes refer to the set of codes used by manufacturers to indicate success, failure, and cause classification during communication. The adapter plugin assigns a corresponding set of error codes to each manufacturer's return code. The set of error codes is the set of fault flags registered in the configuration repository by the card reader access layer. During runtime, the adapter plugin always outputs the codes in the set of error codes to avoid different manufacturers' return codes presenting multiple meanings in the business system.

[0033] By using the above methods, it is ensured that under the same card reader type, regardless of which business system the card reading request comes from or which site the terminal belongs to, as long as it is within the scope of the runtime environment attributes supported by the adapter plugin declaration, the card reading behavior initiated through the card reader access layer remains consistent in terms of field meaning and fault flags.

[0034] Preferably, in a typical government and enterprise site, the number of manufacturer logos can cover several major suppliers, with several model logos configured under each manufacturer. The terminal operating system type in the operating environment attributes can be set to two major categories: desktop environment and mobile environment. The browser kernel type can be set to several commonly used rendering kernel combinations. The site logos are allocated according to the actual number of outlets within the organization. The number of adapter plugins in the plugin directory can be set to be consistent with the number of card reader types. Each adapter plugin is bound to a version number in the configuration repository. When the manufacturer updates the communication manual or a new model is added to the site, the expansion is completed by adding a new version of the adapter plugin and registering the new version record in the configuration repository. Unified access to the newly added card readers is achieved without adjusting the card reader access layer and the business system calling method.

[0035] During on-site operational assessments, a certain number of typical outlets can be selected, and card reading requests in scenarios such as price settlement, visitor registration, and outsourced work order processing can be included in the statistics. The proportion of card reading requests initiated by different business systems that successfully return content according to a unified card data structure and have consistent error code markings within a specified observation period can be examined. This proportion can be used as an assessment indicator for the consistency of the adaptation plugin's behavior. When the indicator is lower than a preset threshold, the configuration repository records and adaptation plugin versions can be checked for troubleshooting and correction, thereby ensuring the feasibility and stability of the adaptation plugin construction scheme in the actual production environment.

[0036] S3. Set a plugin directory in the card reader access layer, scan the plugin directory to obtain attributes, establish a plugin registry based on the card reader type and runtime environment attributes, and load the plugin entity. The specific implementation is as follows: After completing the development of the adaptation plugins, a plugin directory is set in the card reader access layer, and all adaptation plugin files are placed in the plugin directory or its subdirectories. The plugin directory refers to a fixed list of paths maintained by the card reader access layer. Each path corresponds to the location of a set of loadable adaptation plugin files, which are registered and bound to version numbers by the operations and maintenance personnel in the configuration repository. During the startup phase, the card reader access layer reads the current version of the plugin directory list in the configuration repository, traverses each path within a controlled time window, and reads the plugin description content and version number inside each adaptation plugin in an agreed order.

[0037] The plugin description refers to the structured text information embedded in the adapter plugin, which is used to indicate the card reader type and runtime environment attributes corresponding to the adapter plugin. The card reader type consists of the manufacturer's identifier and the model identifier. The runtime environment attributes include the terminal operating system type, browser kernel type, and site identifier. The set of valid values ​​for the manufacturer's identifier, model identifier, terminal operating system type, browser kernel type, and site identifier are registered in advance in the configuration repository.

[0038] When the card reader access layer scans the plugin directory, it compares the manufacturer's identifier, model identifier, and operating environment attributes in the plugin description with the valid values ​​registered in the configuration repository. Records with inconsistent naming are marked as mismatched records and will not be included in the plugin registry for this round. Records with field order that does not conform to the unified standard are rearranged according to the standard order without changing the meaning of the fields before participating in the registration. Plugins that are missing site identifiers or browser kernel categories are marked as pending completion in the plugin status and restricted to being only a backup plugin candidate, and cannot be the preferred plugin for any combination of card reader type and operating environment attributes.

[0039] After completing a directory scan, the card reader access layer constructs a plugin registry based on the verified plugin set. The plugin registry is a list of entries categorized by card reader type and runtime environment attribute combinations. Under each combination, at least one primary plugin entity and zero or more backup plugin entities are attached. The primary plugin entity is the preferred adapter plugin instance selected in the current combination, while backup plugin entities are adapter plugin instances allowed to be enabled when the primary plugin entity is unavailable. For each plugin entity, the plugin registry records the plugin version number, priority, and maintenance status. The plugin version number is consistent with the version number of the adapter plugin itself. The priority is used to determine the selection order among multiple candidate plugins, and the maintenance status indicates whether the plugin is currently in an usable or maintenance state.

[0040] After the plugin registry is built, it is written to the internal storage area of ​​the card reader access layer and associated with the configuration version number in the configuration repository to form a versioned plugin registry snapshot. During the period when the version number is not changed, the card reader access layer always refers to the same plugin registry snapshot when processing subsequent card reading requests to select plugins.

[0041] To adapt to changes in on-site configuration, the card reader access layer performs catalog inspections according to a preset cycle during operation. During the inspection, the aforementioned scanning and comparison process is repeated. New plugin registry entries are generated for newly added plugins, version updates, or path adjustments. After confirming that there are no errors, the system switches to the new snapshot by updating the version number.

[0042] Preferably, the number of plugin directory paths can be set to several, with each path corresponding to a logical area or a type of card reader. The directory inspection cycle can be set to several minutes, and the single scan time window can be set to several seconds. In typical government and enterprise sites, the number of card reader types registered in the plugin registry can be set to several. The number of primary plugin entities under each combination is fixed at one, and the number of backup plugin entities can be set to several. Through the above configuration, all plugin records can be updated within one inspection cycle, while ensuring that the card reader access layer continuously uses the previous version of the plugin registry to process on-site card reading requests during the inspection period. This enables the stable operation and replicable implementation of the plugin directory management and plugin selection mechanism in the actual production environment.

[0043] S4. When the business system issues a card reading request, the card reading access layer parses the terminal environment parameters and the target card reader identifier, searches for candidate plugins in the plugin registry, and selects the target plugin according to priority. The specific implementation is as follows: When a business system sends a card reading request through the internal network, the card reading access layer reads the pre-agreed field content from the request message, first parses the terminal environment parameters, and then parses the target card reader identifier and the card reading request identifier.

[0044] Terminal environment parameters are organized by the front-end component in a unified format and written into the request message. They include at least the operating system type, browser kernel type, and site identifier. The operating system type refers to the type and major version range of the operating system to which the terminal belongs. The browser kernel type refers to the type number of the rendering kernel of the browser used by the terminal. The site identifier refers to the code used to distinguish different physical sites or logical areas. The selectable values ​​of the three are centrally registered by the configuration repository and loaded when the card reader access layer starts.

[0045] The target card reader identifier is pre-assigned by the business rules for each card reading scenario to indicate the type of card reader expected to be used in that scenario. There is a one-to-one or one-to-many mapping relationship between the card reader type and the aforementioned manufacturer identifier and model identifier. The specific mapping table is also stored in the configuration repository.

[0046] The card reader request identifier is a unique identifier assigned by the business system to each card reader action. It is used throughout all steps involved in the card reader action and is generated according to unified rules before the business system generates the request, and is sent to the card reader access layer along with the message. After completing the field parsing, the card reader access layer searches the current version of the plugin registry for a set of candidate plugins that meet the matching conditions of runtime environment attributes and card reader type, based on the key value formed by combining terminal environment parameters and target card reader identifier. For each candidate plugin, the plugin registry provides at least the plugin version number, priority, and availability status. The priority indicates the recommended usage order under this combination, and the availability status indicates whether the plugin is currently in a usable state.

[0047] The card reader access layer sorts the candidate plugins from high to low priority, and determines the first-ranked plugin that is available and on standby as the target plugin. Within a single card reader request link, the card reader request identifier is used as the anchor point to write the relevant information of the target plugin into the temporary session record.

[0048] Temporary session records refer to a collection of short-term session states stored within the card reader access layer. Each record is bound to a card reader request identifier and records the target plugin identifier, plugin version number, session start time, and terminal environment parameters. This is used to maintain consistent plugin selection behavior when duplicate messages occur.

[0049] When the business system triggers the resending of the same card reading request identifier due to network jitter or page interaction, the card reading access layer first searches for the corresponding record in the temporary session record. If the record already exists within the set time window, the target plugin in the record is directly used for subsequent actions, without re-searching the plugin registry, thereby avoiding the situation where multiple plugins alternately participate in the same card reading request in a short period of time.

[0050] In scenarios where there are multiple candidate plugins with the same priority value, the card reader access layer determines a unique order based on a fixed sorting rule pre-registered in the configuration repository. The fixed sorting rule can be based on the lexicographical order of the plugin identifier, the order of the deployment path, or a manually specified order, and remains unchanged within the current plugin registry version. Dynamic adjustment of the sorting rule during runtime is prohibited, so that the selection result of the same combination of plugins remains stable under the same configuration version.

[0051] Throughout the plugin retrieval and selection process, the card reader access layer only accesses the plugin registry snapshot associated with the current configuration version number. It will not mix different version content without version switching, thus ensuring that all card reader requests complete plugin selection under the same rule set within the same time period.

[0052] Preferably, the retention window for temporary session records can be set to several seconds to several tens of seconds, the upper limit of the candidate plugin set can be set to several, and the return flag when no plugin is available can be bound to a specific error code. In a typical scenario of joint deployment of sales portal and government and enterprise portal, statistical analysis of card reading requests with the same terminal environment parameters and target card reader identifier within a continuous period of time shows that the target plugin selection results remain completely consistent under the same configuration version, thus proving the replicability and stability of the plugin retrieval and selection mechanism in actual operation.

[0053] S5. The card reader access layer calls the target plugin to perform device initialization and card detection, performs card reading operations to obtain card information, and encapsulates it into a unified card data object to return to the business system. The specific implementation is as follows: After the target plugin is selected, the card reader access layer triggers the target plugin to participate in this card reader link based on the target plugin identifier in the aforementioned temporary session record. The card reader access layer then executes device initialization, card detection, and card reading operations in sequence according to the card reader control standard interface agreement.

[0054] Device initialization refers to the entire process of the target plug-in opening the communication channel with the card reader in the current terminal environment. Specifically, it includes selecting the corresponding port flag, baud rate parameter and frame format flag on the terminal and applying them to the card reader driver based on the set of manufacturer parameters registered in the configuration repository. The port flag refers to the number used to identify the physical or logical connection channel, the baud rate parameter refers to the setting of the number of symbols transmitted per unit time, and the frame format flag refers to the combination of start bit, stop bit and check bit used during communication.

[0055] The card reader access layer passes the terminal environment parameters and target card reader identifier of the current session to the target plugin. The target plugin retrieves a set of port flags, baud rate parameters and frame format flags corresponding to the terminal environment from the configuration repository, issues configuration actions to the card reader item by item in a fixed order, and confirms that the communication channel is available by the card reader through feedback information within a limited time.

[0056] After successful device initialization, the card reader access layer continues to schedule the target plug-in to perform card detection. Card detection refers to reading the card slot status or sensing area status at a fixed rhythm within a certain continuous time period to determine whether there is a medium to be read. The card slot status refers to the status flag indicating whether the medium is inserted into the mechanical slot, and the sensing area status refers to the status flag indicating whether the medium is detected in the non-contact area.

[0057] According to the manufacturer's publicly available instructions, the target plugin converts the status code from the card slot or sensing area into a unified presence flag. When the card is not present, it returns an error code corresponding to the card not being present to the card reader access layer, and when the card is present, it returns a ready flag to the card reader access layer.

[0058] After receiving the readiness flag, the card reader access layer continues to perform card reading operations through the target plug-in. Card reading operation refers to the process of issuing a set of card reading commands to the media already in place in a predetermined order and obtaining media information from the card reader. The target plug-in collects the card's unique identifier, media category, and cardholder-related information according to the manufacturer's protocol. The card's unique identifier refers to a combination of numbers that can uniquely correspond to a single media in the long term. The media category refers to the identifier used to distinguish the uses of different media. The cardholder-related information refers to a set of fields that can be associated with personnel records in the business system.

[0059] Based on the field mapping relationships registered in the configuration repository, the target plugin assembles the content obtained from the card reader into a unified card data object. This unified card data object includes at least card type flag, card identification number, cardholder flag, issuing institution flag, and extended fields, along with corresponding error code flags. It is then returned to the card reader access layer, which in turn sends it to the requesting business system in the format agreed upon with the business system.

[0060] The card reader access layer treats the card reader request identifier as a unique anchor point throughout the entire link, and only one unified card data object is allowed to be generated under the same card reader request identifier. When a message with the same card reader request identifier is detected to arrive again after the card information has been returned, it is identified as a late message, discarded directly, and a duplicate behavior flag is added to the card reader request identifier in the internal session record. At the same time, the unified card data object returned for the first time is retained unchanged to ensure that the business system side will only receive one stable result for the same card reader request.

[0061] After the card information is successfully returned, the card reader access layer writes the unified card data object and key status flags into the local short-term cache according to the card reader request identifier. The local short-term cache refers to the volatile storage area located on the side of the card reader access layer. Within the set retention time window, the same business system or subsequent business nodes are allowed to request the same unified card data object multiple times through the card reader request identifier without having to repeatedly drive the card reader to complete the reading of the same medium.

[0062] When the retention time window ends or the business system detects that the card reading request identifier has been explicitly released, the card reading access layer deletes the corresponding record from the local short-term cache, releasing on-site resources. Preferably, in the joint deployment of government and enterprise sites and billing sites, the polling rhythm of card detection can be set to once every several hundred milliseconds, the single detection time window can be set to several seconds, and the average time for successful card reading after device initialization can be controlled within several seconds. In a continuous card reading behavior with a sample size of several thousand times, the idempotent control based on the card reading request identifier and the local short-term cache mechanism can make the probability of the business system receiving duplicate content close to zero, and can still maintain the uniqueness and reproducibility of the unified card data object when network jitter occurs. This proves that the card reading link can be stably reproduced under different business scenarios and card reader types.

[0063] S6. If a preset number of communication errors or card reading failures occur during the call process, the card reader access layer selects a backup plugin from the plugin registry to re-execute the initialization and card reading operations, and records the plugin selection result and error information. Specifically, the implementation is as follows: In the card reading link involving the target plugin, the card reading access layer continuously tracks the status of the current session based on the card reading request identifier. When a preset number of communication anomalies occur consecutively during the device initialization phase or card detection phase, or when a unified card data object is not formed after multiple card reading operations are initiated within a set number of times, this situation is identified as a fault scenario that requires switching plugins.

[0064] Communication anomalies refer to the interruption of connection between the device and the card reader during device initialization, round-trip latency exceeding the threshold, or verification results not meeting the agreed conditions when verifying according to the established frame format. Card reading failure refers to the failure to obtain results that meet the field requirements of the unified card data structure after several card reading command sequences have been executed, even though device initialization and card detection have been completed in the current session.

[0065] At this point, the card reader access layer removes the current primary plugin from the plugin entities attached to the plugin entity based on the card reader type and runtime environment attribute combination recorded in the plugin registry. Plugin entities with the same card reader type and runtime environment attributes but with a priority lower than the primary plugin are identified as backup plugins. Backup plugins refer to the adaptable plugin instances in the current combination that are used to take over the role.

[0066] After the card reader access layer selects a backup plugin, it uses the same card reader request identifier as an anchor point to drive the target terminal to perform device initialization and card detection again. It passes the port flag, baud rate parameter and frame format flag that match the current terminal environment to the backup plugin, which then repeats the establishment of communication channel, card presence judgment and execution of card reader command sequence. The newly generated unified card data object is returned to the business system, thereby restoring the card reader capability without changing the business system's calling method.

[0067] To ensure subsequent investigation and accountability, the card reader access layer adds a record to the log warehouse every time it switches from the primary plugin to the backup plugin or when a unified card data object cannot be formed on the backup plugin.

[0068] The log repository refers to an append-only storage area deployed on the card reader access layer side, which is used to save card reading behavior trajectories and fault information. Each record contains at least the card reading request identifier, terminal environment parameters, card reader type, primary plugin version number, backup plugin version number, error code, and time stamp. The time stamp is used to indicate the specific time when the fault occurred, and the error code adopts the encoding value in the current version error code set in the configuration repository.

[0069] The plugin version number recorded in the log repository is mapped to the corresponding version definition in the configuration repository. When the card reader access layer or maintenance personnel adjust the plugin priority, plugin directory or standard interface field, a new version number is generated in the configuration repository, and the version switch time and reason are recorded in the log repository, thus forming a traceable evidence chain from configuration change to on-site fault performance.

[0070] In this way, in actual production settings, it is possible to accurately distinguish whether the primary plugin is no longer compatible with the current browser kernel type or whether the backup plugin does not cover the specific site's identifier range. Preferably, when used in government and enterprise portal settings, the threshold for consecutive communication anomalies can be set to three times, i.e., triggering plugin switching when three consecutive connection interruptions, latency exceeding limits, or frame verification non-compliance occur during device initialization or card detection phases; the number of backup plugin switching attempts can be set to two, i.e., the same card reading request identifier can be tried a maximum of the primary plugin and two levels of backup plugins sequentially; the maximum time limit for a single card reading can be set to several seconds, and failure to form a unified card data object within the time limit is counted as a card reading failure; and the number of successful returns of a unified card data object within 1000 card reading attempts is no less than 990 as a verification criterion. In this scenario, when a browser kernel upgrade causes the primary plugin to continuously exceed a threshold and generate communication anomalies, it is only necessary to replace the plugin file with the new version corresponding to the browser kernel in the plugin directory and update the priority and version number of the primary plugin in the configuration repository. After the card reader access layer completes the next round of plugin registry construction and version locking, it can automatically select the new version plugin. The changes in the distribution of the two version numbers and corresponding error codes in the log repository together constitute the correspondence between version adjustment and fault improvement. This allows engineering technicians to restore and improve the compatibility of the on-site card reader without modifying the code of each business system.

[0071] Example 2: A card reader plug-in compatible system, comprising: The card reader access layer module is used to set up outside the business system and establish a connection with the business system. The card reader access layer defines the standard interface for card reader control, as well as the unified card data structure and error codes. The adapter plugin management module is used to register adapter plugins for various card readers, enabling the adapter plugins to encapsulate the underlying communication logic and implement the standard interface for card reader control. At the same time, it records the card reader type and operating environment attributes for the adapter plugins. The plugin registration module is used to set up a plugin directory in the card reader access layer, scan the adapter plugin files in the plugin directory to obtain the card reader type and runtime environment attributes, and build a plugin registry and load the plugin entity based on the card reader type and runtime environment attributes. The plugin selection module is used to parse terminal environment parameters and target card reader identifier when the business system issues a card reading request, and to search for candidate plugins according to the plugin registry and determine the target plugin according to priority. The card reading execution module is used to call the target plugin through the card reading access layer to perform device initialization and card detection, and to perform card reading operations to obtain card information, encapsulate it into a unified card data object, and return it to the business system; The fault handling module is used to detect communication anomalies and card reading failures after a preset number of consecutive calls during the call process. It then selects a backup plugin based on the plugin registry to re-execute the device initialization and card reading operation, and records the plugin selection result and anomaly information.

[0072] The above description is merely a specific embodiment of this application, but the scope of protection of this application is not limited thereto. Any variations or substitutions that can be easily conceived by those skilled in the art within the scope of the technology disclosed in this application should be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A card reader plug-in compatibility method, characterized in that, include: S1. Set up the card reader access layer, define the standard interface for card reader control, and unify the card data structure and error codes; S2. Build adapter plugins for various card readers. The plugins encapsulate the underlying communication logic and implement standard interfaces, while recording the card reader type and operating environment attributes. S3. Set up a plugin directory in the card reader access layer, scan the plugin directory to obtain attributes, and build a plugin registry and load plugin entities according to the card reader type and runtime environment attributes. S4. When the business system issues a card reading request, the card reading access layer parses the terminal environment parameters and the target card reader identifier, retrieves candidate plugins according to the plugin registry, and selects the target plugin according to priority. S5. The card reader access layer calls the target plugin to perform device initialization and card detection, performs card reading operations to obtain card information and encapsulates it into a unified card data object and returns it to the business system. S6. If a communication error occurs for a preset number of consecutive times or a card reading failure occurs during the call process, the card reading access layer selects a backup plugin based on the plugin registry and re-executes the initialization and card reading operation, and records the plugin selection result and error information.

2. The card reader plug-in compatibility method according to claim 1, characterized in that, S1 includes: The card reader access layer sets up standard interfaces for card reader control, including device initialization, device detection, card detection, card reading, and resource release. The card reader access layer associates the card reader control standard interface definition, unified card data structure definition, and error code set with version numbers in the configuration repository; The unified card data structure includes card type identifier, card identification number, cardholder identifier, and issuing institution identifier; When the card reader access layer starts up, it loads the current version configuration from the configuration repository into memory. When processing card reading requests, it organizes card information according to a unified card data structure and marks card reading failures according to the error code set.

3. The card reader plug-in compatibility method according to claim 1, characterized in that, S2 include: On the server where the card reader access layer is located, an adapter plugin is set up for the field card reader. The adapter plugin is stored as an independent software unit in the plugin directory and is loaded by the card reader access layer. The adapter plugins correspond to the card reader type and operating environment attributes registered in the configuration repository. The card reader type consists of the manufacturer's logo and the model logo. The runtime environment attributes include the terminal operating system type, browser kernel type, and site identifier.

4. The card reader plug-in compatibility method according to claim 3, characterized in that: The adapter plugin maintains the correspondence between the manufacturer's protocol fields and the card type flag, card identification number, cardholder flag, and issuing institution flag in the unified card data structure locally; The content obtained from the card reader will be converted into a Uniform Card Data Object; The adapter plugin assigns fault codes to the manufacturer's return codes based on the set of error codes registered in the configuration repository.

5. The card reader plug-in compatibility method according to claim 1, characterized in that, S3 includes: The card reader access layer registers a list of plugin directories associated with the configuration version number in the configuration repository, and traverses the plugin directories to read the plugin description content at startup; The card reader access layer compares the manufacturer's mark, model mark and operating environment attributes in the plugin description with the values ​​registered in the configuration warehouse to eliminate mismatch records, and marks the compatible plugins with incomplete operating environment attributes as backup plugin candidates. The card reader access layer constructs a plugin registry based on the card reader type and operating environment attributes. Under each combination, the version number, priority, and monitoring status of the primary plugin entity and the backup plugin entity are registered.

6. A card reader plug-in compatibility method according to claim 1, characterized in that, S4 include: When the card reader access layer receives a card reader request sent by the business system, it sequentially parses the terminal environment parameters, the target card reader identifier, and the card reader request identifier from the request message. Based on the terminal environment parameters and the target card reader identifier, candidate plugins are retrieved from the plugin registry snapshot corresponding to the configuration version number, and the target plugin is selected according to priority and duty status. The card reader request identifier and the target plugin identifier are written into the temporary session record. When the card reader request identifier appears repeatedly within a preset time window, the same target plugin is called based on the temporary session record.

7. A card reader plug-in compatibility method according to claim 1, characterized in that, S5 include: The card reader access layer sequentially calls device initialization, card detection, and card reading operations based on the target plug-in identifier in the temporary session record, obtains card information from the card reader, generates a unified card data object according to the field mapping registered in the configuration repository, and returns it to the business system; The card reader access layer uses the card reader request identifier as the unique anchor point and retains only one copy of the unified card data object corresponding to the card reader request identifier in the local short-term cache for subsequent business access.

8. A card reader plug-in compatibility method according to claim 1, characterized in that, S6 include: In the card reading link involving the target plugin, the card reader access layer counts the number of communication anomalies and the number of card reading failures based on the card reading request identifier; When the cumulative number of times reaches the preset number, a backup plugin is selected from entities with the same card reader type and runtime environment attributes but with a lower priority than the primary plugin, based on the plugin registry. Under the card reader request flag, re-execute device initialization, card detection, and card reading operations, and record the card reader request flag, terminal environment parameters, card reader type, primary plugin version number, backup plugin version number, error code, and time stamp in the log warehouse.

9. A card reader plug-in compatibility system, used to implement the card reader plug-in compatibility method according to any one of claims 1-8, characterized in that, include: The card reader access layer module is used to set up outside the business system and establish a connection with the business system. The card reader access layer defines the standard interface for card reader control, as well as the unified card data structure and error codes. The adapter plugin management module is used to register adapter plugins for various card readers, enabling the adapter plugins to encapsulate the underlying communication logic and implement the standard interface for card reader control. At the same time, it records the card reader type and operating environment attributes for the adapter plugins. The plugin registration module is used to set up a plugin directory in the card reader access layer, scan the adapter plugin files in the plugin directory to obtain the card reader type and runtime environment attributes, and build a plugin registry and load the plugin entity based on the card reader type and runtime environment attributes. The plugin selection module is used to parse terminal environment parameters and target card reader identifier when the business system issues a card reading request, and to search for candidate plugins according to the plugin registry and determine the target plugin according to priority. The card reading execution module is used to call the target plugin through the card reading access layer to perform device initialization and card detection, and to perform card reading operations to obtain card information, encapsulate it into a unified card data object, and return it to the business system; The fault handling module is used to detect communication anomalies and card reading failures after a preset number of consecutive calls during the call process. It then selects a backup plugin based on the plugin registry to re-execute the device initialization and card reading operation, and records the plugin selection result and anomaly information.

Images