External social security agency interfacing method and device, and storage medium

Abstract

The application discloses a docking method and device of an external social security agency and a storage medium, and comprises the following steps: receiving a TCP message through a plurality of TCP listening ports which are opened in advance; determining the agency identifier of the external social security agency which sends the TCP message, and analyzing the interface identifier from the TCP message; converting the TCP message into an HTTP request, and adding the agency identifier and the interface identifier to the URL of the HTTP request; forwarding the HTTP request; determining the corresponding specific template subclass according to the agency identifier in the URL, and determining the corresponding strategy class based on the interface identifier; embedding the strategy class into the standard processing flow arranged by the specific template subclass to execute, and completing the message processing of the external social security agency. The application combines a plurality of independent pre-programs into a single set, realizes the centralized deployment of hardware resources and the unified maintenance of public logic, and thus significantly reduces the resource consumption and the development and operation and maintenance cost.

Description

Technical Field

[0001] This application relates to the field of financial data processing technology, and in particular to a method, equipment and storage medium for connecting with external social security institutions. Background Technology

[0002] Occupational annuity is a supplementary pension insurance system for employees of government agencies and public institutions in my country, with each province's occupational annuity fund operating independently. The occupational annuity entrusted operation system assists the trustee in fulfilling its responsibilities and completing data exchange with provincial human resources and social security agencies (agents), custodians, and investment managers. According to the requirements of each provincial human resources and social security bureau, the entrusted operation system must use the TCP communication protocol to interface with the human resources and social security agencies, and the interface standards, message formats, and business processes defined by each province differ significantly. In current production practice, for each provincial human resources and social security bureau, a separate front-end application system needs to be deployed, and corresponding development and verification must be carried out for the province's encryption methods, message structures, and business processes. More than thirty such front-end applications have been deployed in the production environment.

[0003] However, this deployment method requires deploying a separate application for each province, resulting in huge consumption of server and network hardware resources. Furthermore, adding new provinces necessitates repeating the entire development, testing, and deployment process, leading to high manpower costs. Secondly, although the various front-end programs have similar functions, their independent deployment prevents the reuse of common business processing logic (such as message decryption, field validation, and format conversion) across different provinces. When common logic needs modification, operations and maintenance personnel must modify the code of over thirty programs individually and perform regression testing on each, resulting in extremely high program maintenance costs and severely reducing the system's maintainability and scalability.

[0004] The above content is only used to help understand the technical solution of this application and does not represent an admission that the above content is prior art. Summary of the Invention

[0005] The main purpose of this application is to provide a method, equipment and storage medium for connecting with external social security institutions, aiming to solve the technical problems of high resource consumption and high maintenance costs caused by the inability to merge multiple independent front-end programs in the existing occupational pension trust operation system.

[0006] To achieve the above objectives, this application proposes a method for connecting with external social security institutions, applied to the connection equipment of external social security institutions, the method comprising: TCP packets are received through multiple pre-opened TCP listening ports, each of which corresponds to a unique external social security agency; Based on the target TCP listening port reached by the TCP packet, determine the organization identifier of the external social security agency that sent the TCP packet, and parse the interface identifier from the TCP packet; The received TCP packet is converted into an HTTP request, and the organization identifier and the interface identifier are added to the URL of the HTTP request; Forward the HTTP request, wherein an abstract template class and multiple strategy classes are predefined; the abstract template class is instantiated into multiple concrete template subclasses, each concrete template subclass corresponds to at least one common business process of an external social security institution, and each concrete template subclass is associated with one or more of the strategy classes, the strategy classes being used to implement the personalized processing logic of the target interface; The specific template subclass is determined based on the organization identifier in the URL, and the corresponding strategy class is determined based on the interface identifier; The strategy class is embedded into the standard processing flow arranged by the specific template subclass and executed to complete the message processing for the external social security agency.

[0007] In one embodiment, the step of instantiating the abstract template class into multiple concrete template subclasses includes: Obtain the business process definitions of all external social security agencies to be connected; Cluster analysis was performed on the business process definition to group external social security agencies with completely identical business processing step sequences into the same process group; Create a concrete template subclass for each process group, so that the concrete template subclass inherits from the abstract template class and overrides the implementation of the steps in the standard processing flow that are related to the personalized requirements of the process group; For other external social security institutions that are not classified into any special group, a common concrete template subclass is instantiated. The common concrete template subclass directly reuses the default processing logic defined in the abstract template class.

[0008] In one embodiment, the step of determining the organization identifier of the external social security agency that sent the TCP packet based on the target TCP listening port to which the TCP packet arrived includes: Read the locally pre-configured port and agency code mapping table, which records the correspondence between each TCP listening port number and the external social security agency code; The destination port number of the TCP packet is used as the key value to match the corresponding organization code in the mapping table, which is then used as the organization identifier.

[0009] In one embodiment, the step of parsing the interface identifier from the TCP packet includes: Obtain the corresponding message decryption key based on the organization identifier, decrypt the encrypted message body in the TCP message, and obtain the plaintext field; Extract the interface code field with a preset position or preset label from the plaintext field and use it as the interface identifier.

[0010] In one embodiment, the step of converting the received TCP packet into an HTTP request includes: Use the original message body in the TCP packet as the message body of the HTTP request, and set the content type of the HTTP request to encrypted binary stream or text type; The HTTP request is formed by adding the original length field information of the TCP segment to the header of the HTTP request.

[0011] In one embodiment, the standard processing flow includes the following steps: The corresponding decryption algorithm is invoked based on the organization identifier to decrypt the message in the HTTP request and obtain the message field; The message fields are parsed to extract business parameter fields. The extracted business parameter fields are then format-validated to determine whether the field type, length, and value range conform to preset rules. The business parameter fields that pass the verification are then subjected to business validity verification, which includes checking whether the organization code is valid, the interface call permissions, and the message sequence. Based on the field standards of the downstream occupational pension system, the verified business parameter fields are converted into messages in the format required by the downstream system. The converted message is forwarded to the core business interface of the occupational pension trustee operation system. The system receives the response message returned by the downstream system, encrypts the response message by calling the corresponding encryption algorithm according to the institution identifier, and then returns the response to the external social security institution that sent the request.

[0012] In one embodiment, the step of determining the corresponding strategy class based on the interface identifier includes: The interface identifier is passed as an input parameter to the preset policy factory; The strategy factory dynamically searches for and returns the corresponding strategy class instance. The strategy factory registers the mapping relationship between each interface identifier and the strategy class instance.

[0013] In one embodiment, after the step of embedding the strategy class into the standard processing flow arranged by the specific template subclass, the method further includes: When an exception occurs during the execution of the strategy class, the exception is captured and logged; Based on the pre-configured exception handling strategy, it is determined whether to retry, skip the current interface call, return a preset error code to the external social security agency, or report the exception to the occupational pension system's monitoring platform.

[0014] In addition, to achieve the above objectives, this application also proposes a device for connecting to an external social security agency, the device comprising: a memory, a processor, and a computer program stored in the memory and executable on the processor, the computer program being configured to implement the steps of the connection method for external social security agencies as described above.

[0015] In addition, to achieve the above objectives, this application also proposes a storage medium, which is a computer-readable storage medium, on which a computer program is stored, and when the computer program is executed by a processor, it implements the steps of the external social security agency docking method described above.

[0016] One or more technical solutions proposed in this application have at least the following technical effects: Multiple pre-opened TCP listening ports are used to receive TCP packets, each corresponding to a unique external social security institution. Based on the target TCP listening port reached by the TCP packet, the institution identifier of the external social security institution sending the TCP packet is determined, and the interface identifier is parsed from the TCP packet. The received TCP packet is converted into an HTTP request, and the institution identifier and the interface identifier are added to the URL of the HTTP request. The HTTP request is forwarded, where an abstract template class and multiple strategy classes are predefined. The abstract template class is instantiated into multiple concrete template subclasses, each corresponding to at least one common business process of an external social security institution, and each concrete template subclass is associated with one or more strategy classes. The strategy classes are used to implement personalized processing logic for the target interface. The corresponding concrete template subclass is determined based on the institution identifier in the URL, and the corresponding strategy class is determined based on the interface identifier. The strategy class is embedded into the standard processing flow arranged by the concrete template subclass and executed to complete the packet processing for the external social security institution.

[0017] The technical solution of this application merges multiple independent front-end systems into a single unified application, significantly reducing hardware deployment costs; centralized maintenance of common logic and independent configuration of personalized logic greatly reduce development and maintenance workload; at the same time, the system can seamlessly support the HTTP protocol to meet future expansion needs. It realizes a technical leap from independent deployment and decentralized operation and maintenance to unified application, common reuse, personalized flexibility, and multi-protocol compatibility for external institution integration of the occupational annuity entrusted operation system. Attached Figure Description

[0018] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this application and, together with the description, serve to explain the principles of this application.

[0019] To more clearly illustrate the technical solutions in the embodiments of this application or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, for those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0020] Figure 1 This is a flowchart illustrating the first embodiment of the method for connecting with external social security institutions in this application; Figure 2 This is a detailed process diagram based on step S20 in the first embodiment; Figure 3 This is a schematic diagram of another detailed process based on step S20 in the first embodiment; Figure 4 This is a detailed schematic diagram of step S30 in the first embodiment; Figure 5 This is a detailed schematic diagram of step S40 based on the first embodiment; Figure 6 This is a detailed process diagram based on step S50 in the first embodiment; Figure 7 This is a flowchart illustrating the second embodiment of the method for connecting with external social security institutions according to the present invention. Figure 8 This is a system architecture diagram based on a network connection solution; Figure 9 A flowchart illustrating the implementation of a template class; Figure 10 This is a schematic diagram of the hardware operating environment involved in the docking method with external social security institutions in this application embodiment.

[0021] The purpose, features, and advantages of this application will be further explained in conjunction with the embodiments and with reference to the accompanying drawings. Detailed Implementation

[0022] It should be understood that the specific embodiments described herein are merely illustrative of the technical solutions of this application and are not intended to limit this application.

[0023] In the occupational annuity entrusted operation system, data exchange between provincial human resources and social security agencies mainly takes three forms. First, each province deploys its own independent pre-program, resulting in high hardware resource consumption, fragmented common logic, and high maintenance costs. Second, there's an attempt to merge data based on source IP identification, but this relies on network architecture stability and cannot identify packet ownership before decryption. Third, directly copying the merging code reduces physical deployment, but common logic remains fragmented, maintenance workload is not substantially reduced, and it's difficult to support subsequent HTTP protocol extensions.

[0024] None of the above methods can simultaneously achieve hardware integration, unified software logic reuse, multi-source encrypted message recognition without pre-parsing, and multi-protocol compatibility within the same framework. In other words, resource consumption, maintenance efficiency, and scalability cannot be balanced in a coordinated manner.

[0025] This application proposes a method for connecting with external social security agencies, which achieves this through a collaborative approach of multi-port static mapping, TCP-to-HTTP protocol separation, template method orchestration of common processes, and strategy pattern injection of differentiated logic. Specifically: multiple TCP ports are opened, each uniquely bound to one agency; the agency identifier is determined based on the target port, eliminating the need to parse encrypted messages; the TCP message is converted to an HTTP request, and the agency identifier and the parsed interface identifier are added to the URL. The business layer defines an abstract template class to orchestrate standard processing flows; multiple concrete template subclasses are instantiated, corresponding to common processes across provinces; multiple strategy classes are defined to implement personalized logic at the interface level, with each template subclass associated with one or more strategy classes. At runtime, the template subclass is selected based on the agency identifier in the URL, and the strategy class is selected based on the interface identifier. The strategy class is then embedded into the process execution to complete unified processing.

[0026] By employing the above methods, multiple independent front-end systems are merged into a single unified application, significantly reducing hardware deployment costs; common logic is centrally maintained while personalized logic is configured independently, greatly reducing development and maintenance workload; at the same time, the system can seamlessly support the HTTP protocol to meet future expansion needs. This achieves a technological leap for the occupational annuity entrusted operation system's external institution integration from independent deployment and decentralized maintenance to unified application, common reuse, personalized flexibility, and multi-protocol compatibility.

[0027] To better understand the technical solution of this application, a detailed description will be provided below in conjunction with the accompanying drawings and specific implementation methods.

[0028] Based on this, the embodiments of this application provide a method for connecting with external social security institutions, referring to... Figure 1 , Figure 1 This is a flowchart illustrating the first embodiment of the external social security agency connection method of this application. In this embodiment, the external social security agency connection method is applied to the connection equipment of the external social security agency, and includes steps S10~S60: Step S10: Receive TCP packets through multiple pre-opened TCP listening ports, wherein each TCP listening port corresponds to a unique external social security agency; In this embodiment, multiple pre-opened TCP listening ports are used to receive TCP packets from external social security agencies. These TCP listening ports are initialized when the system starts up. Each TCP listening port is bound to a unique port number at the operating system's network layer and establishes a fixed, unchangeable correspondence with an external social security agency. That is, when connecting to the social security bureaus of thirty different provinces, thirty TCP listening ports are opened; for example, port 10001 corresponds to the Beijing social security agency, port 10002 corresponds to the Shanghai social security agency, and so on. This one-to-one binding relationship is recorded in the local configuration file of the system. The system loads this configuration file upon startup and opens all ports according to the configuration.

[0029] The core purpose of employing the aforementioned multi-port static mapping method is to avoid the problem of being unable to identify the source of a message without decrypting it. Because each external social security institution encrypts its TCP packets using its unique encryption key, if only a single general port is opened to receive all messages, the receiving system cannot determine which institution's decryption algorithm to use to decrypt the ciphertext, thus making it impossible to read the message content. However, by opening a separate listening port for each institution, the destination port of the message itself carries the source information, allowing the receiving system to determine the message's origin without parsing the ciphertext. This design completely eliminates the dependence on the network layer source IP address, because internal network address translation or routing policies within the bank may change the source IP of the message, but the destination port remains unchanged during the internal network mapping process. Therefore, this scheme has extremely high stability and reliability.

[0030] In the specific implementation, a high-performance TCP server was developed using Java and based on the Netty framework. Upon startup, a port mapping configuration file is read. This file is in YAML format, with an example content as follows: the organization code corresponding to port 10001 is BJ1001, and the organization code corresponding to port 10002 is SH2002. Each entry also includes auxiliary information such as the encryption algorithm type used by the organization and the key storage path. Netty's ServerBootstrap class binds to each port according to the above configuration and sets an independent ChannelInitializer for each port to handle the TCP packets received on that port. When an external social security organization sends TCP packets via a dedicated line, the packets are routed through the network and eventually reach the receiving server. The operating system distributes the packets to the corresponding Netty channel on the port based on the destination port number in the packet header. Upon receiving the raw byte stream, the channel immediately triggers subsequent processing logic. Through these methods, unified reception and initial aggregation of multi-source packets are achieved.

[0031] Step S20: Based on the target TCP listening port to which the TCP packet arrives, determine the organization identifier of the external social security agency that sent the TCP packet, and parse the interface identifier from the TCP packet; After receiving the TCP packet, the organization identifier of the external social security agency needs to be determined based on the target listening port to which the TCP packet arrives, and the interface identifier needs to be parsed from the encrypted packet body of the TCP packet.

[0032] The processing logic for determining the organization identifier is as follows. Since each TCP listening port has established a fixed one-to-one binding relationship with an external social security organization, when a packet arrives at a port, the corresponding organization identifier can be obtained simply by querying the locally maintained port-to-organization code mapping table. In practice, the ChannelHandlerContext corresponding to each port in the Netty framework stores the organization code bound to that port. When a packet enters the processing chain of that channel, the processor directly obtains the organization code from the context object without performing any additional network queries or database accesses. This method is more efficient and has a lower error probability compared to solutions that parse packet content or analyze the source IP address, because the port number is information that the network protocol stack can obtain at the data link layer, without involving upper-layer protocol parsing or being affected by network address translation.

[0033] Furthermore, the processing logic for parsing interface identifiers needs to overcome the obstacle of different encryption methods used by different provinces. Different external social security agencies use their own independent encryption algorithms; for example, some use SM4 symmetric encryption, some use 3DES, and some use custom XOR scrambling algorithms, and each agency holds a different key. Before decryption, the entire message body is in an encrypted state, and the interface code fields cannot be read directly. Therefore, this step first uses the agency identifier already determined in the first task to obtain the decryption algorithm type and decryption key corresponding to that agency from the configuration center. The configuration center can be a local encrypted configuration file or a remote configuration management service, such as Apollo or Nacos. After obtaining the decryption algorithm and key, the decryptor is dynamically instantiated using Java's reflection mechanism or a pre-loaded algorithm factory to perform decryption operations on the encrypted message body in the TCP packet, obtaining a plaintext XML or JSON format string.

[0034] After successful decryption, the plaintext string contains the interface information for the request. While the message formats defined by different provincial human resources and social security agencies vary, they typically identify the interface code in fixed locations or using fixed tags. For example, there might be a tag named "interfaceCode" under the root node of an XML message, or a field named "apiName" in a JSON object. Based on the agency's pre-configured message format description template, the value of the interface code field is extracted from the plaintext field as the interface identifier. If an agency's message format is unique, and the interface code appears in a dynamic location, custom extraction logic can be implemented using the agency's corresponding strategy class. Through these two steps, the agency identifier and interface identifier are obtained, providing the necessary context information for subsequent protocol conversion and business orchestration.

[0035] Step S30: Convert the received TCP packet into an HTTP request, and add the organization identifier and the interface identifier to the URL of the HTTP request; After obtaining the organization identifier and interface identifier, the received TCP packets are converted into HTTP requests, and the organization identifier and interface identifier are added to the URL of the HTTP request. The core purpose of this conversion step is to decouple the network communication protocol from the business processing logic, so that the backend business processing layer does not need to care whether the packets were originally transmitted via TCP or HTTP protocol, while also reserving room for future expansion to support HTTP protocol modifications for human resources and social security organizations.

[0036] In the specific implementation, the complete TCP packet content is first read from Netty's ByteBuf, which includes a length field and an encrypted packet body. This raw packet body is temporarily stored as a byte array, and then a standard HTTP request object is constructed. In a Java environment, this object can be created using the Request.Builder class provided by the Apache HttpClient or OkHttp libraries. When constructing an HTTP request, three elements need to be determined: the request method, the URL, and the target address. The POST method is used uniformly because all business requests are data submission or query types, and the POST method can carry a large packet body. The target address is the unified service entry point provided by the backend business processing layer, such as "http: / / localhost:8080 / proxy / handle".

[0037] Next, the organization identifier and interface identifier are added to the URL. Specifically, query parameters are appended to the base URL. For example, if the original base URL is "http: / / localhost:8080 / proxy / handle", the organization identifier is "BJ1001", and the interface identifier is "QUERY_BALANCE", then the complete URL after appending is: "http: / / localhost:8080 / proxy / handle?orgCode=BJ1001&apiCode=QUERY_BALANCE".

[0038] The advantage of using URL query parameters to pass the above identifiers is that this method does not modify the content of the HTTP request body, maintaining the integrity of the original message. Simultaneously, the downstream business processing layer can easily extract parameters from the request object without needing to parse the message again to obtain the organization identifier and interface identifier. To avoid encoding problems caused by Chinese characters or special characters, the system performs URLEncoder encoding on the organization identifier and interface identifier before concatenation.

[0039] After completing the URL concatenation, the encrypted message body from the original TCP packet is set as the HTTP request body in the aforementioned request object, and the Content-Type header is set to: "application / octet-stream"; This indicates that the message body is binary data. Furthermore, the system adds the original TCP packet length field information to the HTTP header, such as an "X-Original-Length" header, whose value is the length field value parsed from the TCP packet, for downstream services to verify packet integrity. Finally, the system sets connection timeout and read timeout to prevent resource blocking due to slow downstream service responses. Through these processes, the encrypted packet originally transmitted via TCP is completely encapsulated in an HTTP request, and the organization identifier and interface identifier are explicitly appended to the URL as query parameters, preparing for subsequent routing and policy invocation.

[0040] Step S40: Forward the HTTP request, wherein an abstract template class and multiple strategy classes are predefined; the abstract template class is instantiated into multiple concrete template subclasses, each concrete template subclass corresponds to at least one common business process of an external social security institution, and each concrete template subclass is associated with one or more of the strategy classes, the strategy classes being used to implement the personalized processing logic of the target interface; After constructing the HTTP request, the request is forwarded. Before or simultaneously with forwarding, an abstract template class and several strategy classes have been predefined. These classes form the skeleton supporting the entire business processing flow. The following details the definition and instantiation process of the abstract template class, concrete template subclasses, and strategy classes. This definition work is completed during system startup, rather than being repeated every time a request is forwarded.

[0041] The abstract template class is an abstract base class named "BaseProcessTemplate". This class defines a template method "executeProcess", which arranges seven standard processing steps for interfacing with external social security agencies in a fixed order: message decryption, field parsing, format validation, business validation, field conversion, forwarding to downstream systems, and encrypted response. Each of these steps corresponds to an abstract method or hook method in the abstract template class. The common, agency-invariant parts can be provided with default implementations, while the customized parts are overridden by subclasses.

[0042] When instantiating an abstract template class into multiple concrete template subclasses, this solution clusters and groups them based on the similarity of business processes across provinces, rather than creating a separate subclass for each province. After analyzing the business processes of over thirty provinces, it was found that most provinces have identical processing flows, which can be grouped into a common process group; Jiangxi Province has some special validation rules, so it is grouped into a separate group; Jiangsu Province has additional field conversion requirements, so it is grouped into a separate group. Based on these groupings, the system creates three concrete template subclasses: "CommonProcessTemplate", "JiangxiProcessTemplate", and "JiangsuProcessTemplate". Each concrete template subclass inherits from the abstract template class and overrides the corresponding hook methods according to the characteristics of its group. For example, CommonProcessTemplate directly reuses all default implementations from the abstract template class; JiangxiProcessTemplate overrides the business validation methods, adding validation logic specific to Jiangxi; and JiangsuProcessTemplate overrides the field conversion methods, adding conversion rules specific to Jiangsu.

[0043] Strategy classes are used to implement personalized processing logic for target interfaces within a single external social security agency, offering finer granularity than concrete template subclasses. Each strategy class implements a unified strategy interface, "ApiStrategy," which declares an "execute" method that receives request parameters and returns the processing result. For each "province + interface" combination requiring personalized processing, the system creates a corresponding strategy class. For example, the balance query interface for the Beijing social security agency needs to call an additional external service to verify account status, so a "BjQueryBalanceStrategy" class is created; the payment interface for the Shanghai social security agency needs to insert a special signature header into the request message, so a "ShPayStrategy" class is created. A relationship is established between strategy classes and concrete template subclasses. Each concrete template subclass internally maintains a Map, where the key is the interface identifier and the value is the corresponding strategy class instance. For example, CommonProcessTemplate registers strategy classes corresponding to various interfaces for most provinces, including Beijing and Shanghai; while JiangxiProcessTemplate, in addition to registering strategy classes specific to Jiangxi, may also reuse some common strategy classes. Through this layered design, common processes are implemented centrally in template subclasses, while personalized logic at the interface level is flexibly injected through strategy classes. The two are both separated and coordinated, which greatly reduces code duplication and maintenance costs.

[0044] After completing the above definition and instantiation, the HTTP request forwarding action is executed. An HTTP client is used to send the constructed request to the local or remote business processing service. Since the business processing service and the protocol conversion service can be deployed in the same process or separately, this embodiment uses embedded forwarding within the same process, i.e., directly calling the entry method of the business processing layer to avoid network overhead. During forwarding, the organization identifier and interface identifier in the above URL are passed to the business processing layer along with the request.

[0045] Step S50: Determine the corresponding specific template subclass based on the organization identifier in the URL, and determine the corresponding strategy class based on the interface identifier; After forwarding the HTTP request to the business processing layer, the corresponding specific template subclass is determined based on the organization identifier in the URL, and the corresponding strategy class is determined based on the interface identifier. This step is the key bridge connecting static configuration and dynamic execution, and its core lies in implementing an efficient and accurate route lookup mechanism.

[0046] First, the specific template subclass is determined. After receiving the HTTP request, the business processing layer extracts the organization identifier from the URL query parameters of the request object, for example, "BJ1001". A mapping table between organization codes and specific template subclass instances is maintained in advance. This table is initialized at system startup based on the grouping information in the configuration file or database. For example, the mapping table records organization codes "BJ1001", "SH2002", "GZ3003", etc., which are all mapped to singleton instances of CommonProcessTemplate; organization code "JX4004" is mapped to an instance of JiangxiProcessTemplate; organization code "JS5005" is mapped to an instance of JiangsuProcessTemplate. The above mapping relationship can also be dynamically adjusted through annotations or configuration files without modifying the code. This step uses the above organization identifier as the key to perform a lookup operation with O(1) time complexity in the above mapping table to quickly obtain the corresponding specific template subclass instance. If the corresponding mapping entry is not found, the system throws an "Unsupported organization" exception and returns an error response.

[0047] Secondly, the strategy class needs to be determined. After obtaining a specific template subclass instance, the strategy class associated with that template subclass needs to be located based on the interface identifier. Each specific template subclass internally holds a strategy factory object, which registers the mapping relationship between all interface identifiers and strategy class instances within the scope of the template subclass. The registration process is also completed during system startup. For CommonProcessTemplate, it iterates through the strategy configurations of all common interfaces, associating interface identifiers such as "QUERY_BALANCE", "PAY", and "CHANGE_INFO" with their corresponding strategy class instances. For JiangxiProcessTemplate, it registers Jiangxi-specific interface identifiers and their strategy classes. For interface identifiers not registered in the Jiangxi-specific list, a default mapping pointing to a common strategy class can be configured, thereby enabling strategy reuse.

[0048] Once the business logic layer receives the interface identifier, it passes it to the strategy factory of the current concrete template subclass. The factory returns the corresponding strategy class instance based on the interface identifier. If the interface identifier is not explicitly registered in the factory, a default strategy class is returned, which implements the most general processing logic. If even the default strategy class does not exist, an "Unsupported Interface" exception is thrown. The above lookup process also uses a Map data structure to ensure high efficiency.

[0049] It's important to note that strategy class instances can be stateless singleton objects or stateful objects dynamically created based on the request content. In this embodiment, all strategy classes are designed as stateless singletons to reduce memory usage and garbage collection overhead. Each strategy class implementation follows the open / closed principle; adding personalized logic to a new interface only requires adding a new strategy class and registering it in the configuration, without needing to modify existing template subclasses or other strategy classes. Through the above processing, the specific template subclass and strategy class instance required to handle the current request are successfully located, preparing for the next step of execution.

[0050] Step S60: The strategy class is embedded into the standard processing flow arranged by the specific template subclass and executed to complete the message processing of the external social security agency.

[0051] After determining the specific template subclass and strategy class, the strategy class is embedded into the standard processing flow arranged by the specific template subclass for execution, thereby completing the full processing of messages from external social security institutions. This step embodies the deep integration of the template method pattern and the strategy pattern, and is the key to achieving a unified approach of common reuse and individual flexibility in this invention.

[0052] The concrete template subclass defines a standard processing flow consisting of seven steps in a fixed order. When the template method of the concrete template subclass is called, it executes these steps sequentially. However, some steps in the above flow are not entirely completed by the template subclass itself, but need to be delegated to the strategy class. For example, in the "field conversion" step, different interfaces may need to convert the raw message into different output formats; some need to be converted to XML, some to JSON, and some may even need to call remote services for data supplementation. These personalized requirements cannot be hardcoded in the template subclass, so the template subclass reserves strategy call points in its design.

[0053] In practice, the business processing layer first calls the template method of the selected template subclass, passing in parameters such as the HTTP request, organization identifier, interface identifier, and the original message body. The template method then executes the first step sequentially: message decryption. In this step, the template subclass obtains the decryption algorithm and key based on the organization identifier and decrypts the message body. This step typically does not require the involvement of the strategy class, as the decryption logic is generally uniform across provinces and does not vary from interface to interface. The second step is field parsing, also completed by the template subclass, which parses the decrypted string into key-value pairs or object structures. The third step is format validation. The template subclass first performs some general validations, such as field non-empty and length limits, and then checks whether the current interface identifier is associated with a strategy class. If it exists and the strategy class implements a validation hook, the template subclass calls the custom validation method of that strategy class to execute the interface-level special validation rules. The fourth step is business validation. Similarly, the template subclass first performs general business validation at the province level, and then calls the personalized business validation method of the strategy class. The fifth step is field conversion, which is the step in which the strategy class intervenes most frequently. The template subclass iterates through the list of fields to be transformed. For each field, if the strategy class provides transformation rules, the transformation logic of the strategy class is used; otherwise, the default transformation logic of the template subclass is used. The sixth step is forwarding to the downstream occupational pension system. The template subclass sends the transformed message to the core business interface and waits for a response. The seventh step is encrypting the response. The template subclass obtains the result returned by the downstream system, calls the corresponding encryption algorithm based on the institution identifier to encrypt the response message, and then returns it to the external social security institution that sent the request.

[0054] Throughout the process, the strategy class is invoked multiple times, but each invocation is embedded into a fixed process within the template subclass via delegation. The strategy class is unconcerned with the overall process orchestration, focusing solely on implementing its assigned, specific piece of customized logic. This design allows developers to add a new interface simply by writing a single strategy class, implementing its unique validation and conversion methods, and registering it with the corresponding template subclass's strategy factory. No modifications to the template subclass's code or the logic of other interfaces are required. When modifying common logic, developers only need to modify the corresponding methods in the abstract template class or concrete template subclass. All strategy classes using this template subclass automatically inherit the modified behavior, eliminating the need for individual adjustments. Through this process, the final processing of external social security agency messages is achieved in a highly cohesive and loosely coupled manner, realizing the technical goal proposed in this invention: merging over thirty independent pre-processing procedures into a single set while simultaneously ensuring the reuse of common logic and flexible configuration of customized logic.

[0055] Furthermore, based on the standard processing flow shown above, the specific steps include: The corresponding decryption algorithm is invoked based on the organization identifier to decrypt the message in the HTTP request and obtain the message field; The message fields are parsed to extract business parameter fields. The extracted business parameter fields are then format-validated to determine whether the field type, length, and value range conform to preset rules. The business parameter fields that pass the verification are then subjected to business validity verification, which includes checking whether the organization code is valid, the interface call permissions, and the message sequence. Based on the field standards of the downstream occupational pension system, the verified business parameter fields are converted into messages in the format required by the downstream system. The converted message is forwarded to the core business interface of the occupational pension trustee operation system. The system receives the response message returned by the downstream system, encrypts the response message by calling the corresponding encryption algorithm according to the institution identifier, and then returns the response to the external social security institution that sent the request.

[0056] In this embodiment, the aforementioned standard processing flow, as a concrete implementation of the template method defined in the abstract template class, comprises seven sequentially linked processing steps. The core design principle of this flow is to standardize and modularize the processing of messages from external social security agencies, enabling most provinces to reuse the same set of process logic, while reserving personalized extension points for a few special provinces or special interfaces. The above seven steps must be executed in a fixed order; any exception in any step will terminate the entire process and return an error response. The processing logic and specific implementation methods of each step are described in detail below.

[0057] The system invokes the corresponding decryption algorithm based on the organization identifier to decrypt the message in the HTTP request, obtaining the message fields. Since different external social security organizations use their own independent encryption algorithms and keys—for example, some use the SM4 national cryptographic algorithm, some use AES, some use RSA, and some even use custom XOR scrambling methods—it is necessary to select a suitable decryptor based on the organization identifier determined in the previous steps. In the specific implementation, a decryptor factory is initialized when the business processing layer starts. This factory caches decryptor instances corresponding to each organization, using the organization code as the key. Each decryptor encapsulates the organization's decryption algorithm type, key, and necessary initialization vector parameters. When the process reaches the decryption step, the system passes the organization identifier as a parameter to the factory, which returns the corresponding decryptor. Subsequently, the decryptor performs a decryption operation on the message body of the HTTP request, i.e., the original encrypted message body. The message body is stored as ciphertext in binary byte stream format. Successful decryption yields a plaintext string, typically in XML or JSON format, containing all the business fields of this request. If decryption fails, for example, due to an incorrect key or corrupted ciphertext, the system immediately throws a decryption exception, logs the error, and returns a "decryption failed" response to the external social security agency, without proceeding with further steps.

[0058] The above message fields are parsed to extract business parameter fields, and the extracted business parameter fields are then format-validated to determine whether the field type, length, and value range conform to preset rules. The decrypted plaintext string is semi-structured text data, which needs to be parsed into a data structure that can be manipulated by the program. The above parsing operation is performed according to the message format definition pre-configured by the organization. For example, for XML format, XPath expressions are used to extract the text values ​​of each node; for JSON format, Jackson or Gson libraries are used to parse it into a Map object. After parsing, a set of key-value pair business parameter fields is obtained, including organization code, interface code, business transaction number, payment amount, personal account information, etc. Format validation is then performed, which is a lightweight input validation designed to prevent obviously non-compliant data from entering subsequent processing stages. The format validation rules are also configured by the organization. For example, one field must be a numeric type and no more than 10 digits long, and another field must conform to the regular expression "^[A-Z0-9]+$". The system iterates through each business parameter field, calling a preset validator to check if its type is correct, its length is within the allowed range, and its value belongs to a valid value in the enumeration list. If any field fails format validation, the system returns a clear error message, such as "The value of field XXX should be a number, but a string was actually received," and terminates the process. Messages that pass format validation proceed to the next step of processing.

[0059] Business parameter fields that pass validation undergo business validity verification. This verification includes checking the validity of the organization code, API call permissions, and message timing. While format validation only verifies the correctness of the field's form, business validity verification verifies the semantic validity of the field content. Specifically, first, it checks whether the organization code matches the organization identifier transmitted in the URL to prevent mismatches between message content and transmission channels. It also verifies whether the organization code is active in the system; if the organization is disabled or not yet active, the request is rejected. Second, it verifies API call permissions to determine if the organization has the authority to call the API corresponding to the current request. Some advanced APIs may only be available to certain provinces; this verification prevents unauthorized access. Finally, it verifies message timing to check whether the difference between the timestamp carried in the message and the server's current time is within the allowed range. For example, the time difference may not exceed five minutes to prevent replay attacks. These business validation rules can be configured differently depending on the organization. For example, Jiangxi Province may require additional permission verification steps, while Jiangsu Province may have a more lenient tolerance for timestamp verification. If the business validity verification fails, the system returns the corresponding business error code and terminates the process.

[0060] Based on the field standards of the downstream occupational pension system, the validated business parameter fields are converted into messages in the format required by the downstream system. The core business interface of the occupational pension entrusted operation system defines a unified internal data exchange standard, including field naming conventions, data type definitions, and nested structure requirements. However, the message formats sent by external social security institutions vary. For example, some institutions name the "personal name" field as "name", some as "userName", and some use the Chinese pinyin "gerenxingming". The purpose of the above conversion steps is to uniformly map heterogeneous data from different sources to a standard format that the downstream system can recognize. During the conversion process, the system performs mapping operations based on a pre-configured field mapping table. The mapping table records the correspondence between source field names and target field names, as well as necessary type conversion rules, such as converting string-formatted amounts to Long type fractional values. For simple field renaming, it can be completed directly through configuration; for complex conversion logic, such as needing to concatenate multiple source fields into a single target field, or needing to call external services for data supplementation, the corresponding strategy class of the interface implements custom conversion. After the conversion is complete, the system constructs a standard format request object, which contains all the business parameters required by the downstream system.

[0061] The converted message is forwarded to the core business interface of the occupational pension entrusted operation system. After the previous four steps, the original message has been converted into an internal standard format that the downstream system can directly process. This step initiates the call to the downstream system, typically via HTTP or RPC to the business interface exposed by the occupational pension entrusted operation system. In practice, the system uses a configured HTTP client or Dubbo service proxy to serialize the request object in the aforementioned standard format into the format required by the downstream interface, such as JSON or Protobuf, before sending the request. To improve the system's fault tolerance, this step sets a reasonable timeout, such as five seconds, and configures a retry policy, allowing for automatic retrying once for temporary failures such as network jitter. Simultaneously, the system records the request ID, start time, and end time of this call for end-to-end monitoring and troubleshooting. If the downstream system returns an error response, this step does not immediately return it to the external social security agency but instead passes the error response to the next step for unified processing.

[0062] The system receives the response message from the downstream system, encrypts it using the corresponding encryption algorithm based on the institution identifier, and then returns the response to the external social security institution that sent the request. The response message returned by the downstream occupational pension system after processing the business request is usually in plaintext format, using the aforementioned internal unified standard. Since the external social security institution requires the response message to be encrypted according to its encryption specifications, this step first obtains the response content returned by the downstream system, then finds the corresponding encryptor based on the institution identifier. This encryptor is paired with the decryptor from the first step, using the same algorithm and key. The encryptor performs an encryption operation on the response message body, obtaining a ciphertext byte stream. Subsequently, the system assembles the response message according to the format required by the institution, typically adding a length field before the ciphertext, indicating the byte length of the ciphertext. After assembly, the complete response message is written back to the TCP connection. Since the original request was received through a TCP port, the response must be returned to the external social security institution through the same TCP connection. Throughout the process, if any step encounters an exception, this embodiment also includes a unified exception handling mechanism. After capturing the exception, it determines whether to return a preset error code or report the exception to the monitoring platform based on the configuration. Through the sequential execution of the above seven steps, a complete request from an external social security agency is correctly processed. The entire process embodies the core idea of ​​the template method pattern: separating the fixed algorithm skeleton from the variable steps.

[0063] Furthermore, you can also view Figure 2 , Figure 2 This is a detailed process diagram based on step S20 in the first embodiment. Figure 2The step of determining the organization identifier of the external social security agency that sent the TCP packet based on the target TCP listening port to which the TCP packet arrived includes S21~23: Step S21: Read the locally pre-configured port and agency code mapping table, which records the correspondence between each TCP listening port number and the external social security agency code; Step S22: Use the destination port number of the TCP packet as a key value to match the corresponding organization code in the mapping table, and use it as the organization identifier.

[0064] In this embodiment, the operation of determining the organization identifier based on the target listening port reached by the TCP packet is further implemented through the content indicated in this embodiment. The core of this set of steps lies in using a locally pre-configured port-to-organization code mapping table to directly convert the target port number obtained by the network layer into an organization identifier that the business layer can recognize, thereby avoiding the parsing of encrypted packet content or dependence on the source IP address.

[0065] First, the pre-configured port-to-organization code mapping table is read. This mapping table is a data structure loaded into memory from the configuration file when the system starts. It is typically implemented using Java's ConcurrentHashMap to ensure thread safety in high-concurrency scenarios. The keys of this mapping table are the TCP listening port numbers, and the values ​​are the corresponding external social security agency codes. For example, port 10001 corresponds to the agency code "BJ1001" representing the Beijing social security agency, port 10002 corresponds to "SH2002" representing the Shanghai social security agency, and port 10003 corresponds to "GZ3003" representing the Guangzhou social security agency. The mapping table records a one-to-one correspondence; each port number uniquely corresponds to one agency code, and each agency code uniquely corresponds to one port number. This bidirectional uniqueness ensures the deterministic identification of the packet source. The configuration file can be in the format of a Properties file, a YAML file, or a JSON file. During system startup, a configuration loader reads and parses the file, storing the parsed key-value pairs into the mapping table. To handle configuration changes that may occur during operation, the system can also monitor changes to the configuration file and perform hot updates without restarting the service.

[0066] The destination port number of the TCP packet is used as the key to match the corresponding organization code in the aforementioned mapping table, serving as the organization identifier for the packet. In practice, when the Netty framework receives a TCP packet, it creates a ChannelHandlerContext object for each channel, containing local and remote address information. This step calls the localAddress() method from the context object to obtain the local SocketAddress, and then further extracts the port number, for example, "10001". Subsequently, the system uses this port number as the key to perform a lookup operation in the loaded port-to-organization code mapping table. Since the mapping table is implemented based on a hash table, the lookup time complexity is constant, and even with hundreds of ports, performance will not be affected. If the lookup is successful, the system returns the corresponding organization code, such as "BJ1001". If the lookup fails, meaning the mapping table does not contain a record for that port number, it indicates that a packet from an unconfigured port was received. In this case, the system logs an error, closes the connection, and returns an "Unknown Organization" response.

[0067] The target port number used in this embodiment is configured internally within the docking system and is unaffected by changes in the external network environment. This is because the target port number remains constant throughout the network path from the external social security agency's dedicated line to the docking server. Even if the internal network undergoes address translation, only the source IP and source port will change; the target port will not be modified. Therefore, this solution offers extremely high stability and reliability.

[0068] Through the above process, the organizational identifier of an external social security institution can be obtained quickly and accurately without parsing the message content or relying on network layer source information. This organizational identifier will be used in subsequent stages such as decryption algorithm selection, template subclass routing, and policy class lookup, and is the foundational information for the entire interface method.

[0069] Furthermore, you can also view Figure 3 , Figure 3 This is a schematic diagram of another detailed process based on step S20 in the first embodiment. Figure 3 The step of parsing the interface identifier from the TCP packet includes S23-24: Step S23: Obtain the corresponding message decryption key according to the organization identifier, and decrypt the encrypted message body in the TCP message to obtain the plaintext field; Step S24: Extract the interface code field with a preset position or preset tag from the plaintext field and use it as the interface identifier.

[0070] In this embodiment, since the TCP packet body sent by the external social security agency is encrypted, the interface code field cannot be read directly. Therefore, decryption is necessary to extract the interface identifier. However, the specific algorithm and key required for decryption depend on the originating agency of the packet, creating a circular dependency: without knowing the origin, decryption is impossible; without decryption, the origin cannot be known. To resolve this contradiction, this embodiment uses port mapping to obtain the agency identifier, which is then used to obtain the corresponding decryption key, thereby decrypting the encrypted packet body and extracting the interface identifier.

[0071] The system obtains the corresponding message decryption key based on the organization identifier and decrypts the encrypted message body in the TCP packet to obtain the plaintext field. After obtaining the organization identifier, such as "BJ1001", the system needs to obtain the decryption algorithm type and decryption key corresponding to that organization. This information is usually stored in a secure configuration center or a locally encrypted configuration file. To avoid key leakage, it is recommended to use a hardware security module or key management service to store and provide keys in actual deployments. This embodiment adopts a relatively simple and secure implementation method: when the system starts, it pulls the encryption configuration of all organizations from the remote configuration center, including algorithm name, key ciphertext, and initialization vector. The key ciphertext is encrypted during transmission and storage, and is only decrypted and loaded into memory using a master key when needed. Then, the corresponding decryptor is obtained from the memory cache based on the organization identifier. This decryptor already contains the correct algorithm and key instance. Subsequently, the encrypted message body is extracted from the original TCP packet. The structure of a TCP packet is usually "length field (4 bytes) + encrypted message body (size specified by the length field)". The system reads the byte array of the encrypted message body, calls the decryptor's decryption method, takes the ciphertext as input, and outputs the plaintext string. The plaintext string's encoding format is typically UTF-8 or GBK, which needs to be specified according to the organization's configuration. If an exception is thrown during decryption, such as an incorrect key or incorrect ciphertext format, the system immediately returns a decryption failure response and logs detailed error information for maintenance personnel to troubleshoot.

[0072] Extract the interface code field with a preset position or preset tag from the above plaintext fields, and use it as the interface identifier. The plaintext field obtained after successful decryption is a structured text, which may be in XML, JSON, or a custom fixed-length format. Different external social security agencies use different formats, so the method for extracting the interface code also needs to be configured differently for each agency. For agencies using XML format, for example, the message root node is... <request>It contains a child node. <interfacecode> QUERY_BALANCE< / interfacecode> The system can use the XPath expression " / Request / InterfaceCode" to extract the text content of the node as the interface identifier. For organizations using JSON format, such as a message with content like {"apiCode":"PAY", "data":{...}}, the system can use the JSON path expression "$.apiCode" to extract "PAY" as the interface identifier. For organizations using a custom fixed-length format, the interface code may appear at a fixed offset, such as 8 bytes starting from the 10th byte. The system will then truncate the string according to the configured starting position and length. All the above extraction rules are defined separately for each organization in the configuration file. These rules are loaded at startup, and a corresponding extractor object is generated for each organization. The system selects the appropriate extractor based on the organization identifier, calls its extraction method, and obtains the interface code string from the plaintext field.

[0073] It is important to note that the aforementioned interface identifiers typically correspond to specific business interfaces defined by the organization. For example, "QUERY_BALANCE" represents the balance query interface, "PAY" represents the payment interface, and "CHANGE_INFO" represents the information change interface. This interface identifier will be used subsequently to find the corresponding policy class, thereby enabling personalized processing at the interface level. Through the above processing, the interface identifier was successfully parsed from the encrypted TCP packet. Simultaneously, the complete plaintext packet content was also obtained, which will be used for subsequent format verification, business verification, and field conversion. These two steps work closely together, solving the problem of directly reading encrypted packets while avoiding the introduction of additional network dependencies for decryption, thus ensuring processing efficiency.

[0074] Furthermore, you can also view Figure 4 , Figure 4 This is a detailed process diagram based on step S30 in the first embodiment. Figure 4 The step of converting the received TCP packet into an HTTP request includes S31-33: Step S31: Use the original packet body in the TCP packet as the message body of the HTTP request, and set the content type of the HTTP request to encrypted binary stream or text type. Step S32: Add the original length field information of the TCP packet to the header of the HTTP request to form the HTTP request.

[0075] In this embodiment, the core of converting the received TCP packet into an HTTP request lies in how to completely preserve the valid information in the original TCP packet, while passing it to the downstream business processing layer in the form of a standard HTTP protocol, so as to ensure that the downstream can obtain all the data required for decryption, verification and forwarding.

[0076] The original TCP packet body is used as the HTTP request body, and the content type of the HTTP request is set to encrypted binary stream or text. The original TCP packet typically consists of two parts: a length field and an encrypted packet body. The length field generally occupies 4 bytes and is used to indicate the byte length of the subsequent encrypted packet body; the encrypted packet body is binary data encrypted by an external security agency, possibly ciphertext encrypted with SM4, AES, or other algorithms. During the conversion process, the system needs to extract the encrypted packet body intact, without any decoding, transcoding, or format modification, because any alteration to the ciphertext will cause downstream decryption failure. In practice, the TCP packet received by the Netty framework is encapsulated in a ByteBuf object. The system first reads the first 4 bytes to obtain the length field value, and then extracts a byte array of the corresponding length from the ByteBuf based on this value; this is the original encrypted packet body. Subsequently, the system uses the OkHttp or Apache HttpClient library to construct a Request object and calls its body method to set this byte array as the request body. At the same time, the system needs to set the Content-Type field in the HTTP header. Since the message body is encrypted binary data without a fixed text encoding or MIME type, it is typically set to "application / octet-stream," which indicates binary stream data. Downstream devices will process it in binary format. If the organization requires the encrypted message body to be Base64 encoded before transmission as text, the Content-Type can be set to "text / plain," and a Base64 string can be placed in the message body. This example illustrates the most common method: directly transmitting the binary stream. Setting the correct Content-Type is crucial; it tells the downstream how to parse the message body. If set incorrectly, the downstream may attempt to decode the binary data as text, resulting in garbled text or decryption failure.

[0077] The raw length field of the TCP segment is added to the HTTP request header to form a complete HTTP request. The length field is another key piece of information in the TCP segment besides the encrypted message body; it records the actual byte length of the encrypted message body. After receiving the HTTP request, the downstream business processing layer needs to decrypt the message body. However, the decrypted plaintext fields sometimes need to be compared with the original length to verify the integrity of the message and prevent truncation or data loss during network transmission. Therefore, this step passes the raw length field information to the downstream as an HTTP header. In specific implementation, the system adds a custom header when constructing the HTTP request, for example, named "X-Original-Length," whose value is set to the read length field value. This value is an integer and needs to be converted to a string. In addition to the length field, the system can also add other auxiliary headers as needed, such as setting "X-Protocol-Type" to "TCP" to identify the original protocol type; and setting "X-Receive-Timestamp" to the system time of the received message for downstream timing verification. The above headers are all added to the standard header area of ​​an HTTP request in the form of string key-value pairs. They do not occupy message body space and do not affect the integrity of the original message content.

[0078] After completing the above two steps, a complete HTTP request object is constructed. This request contains the following elements: the request method is POST; the request URL is the base path followed by query parameters for the organization identifier and interface identifier; the HTTP header contains the original length field information and other auxiliary information; the HTTP message body is the original encrypted message body, without any modification. This request is submitted to the HTTP client, ready to be forwarded to the business processing layer. Through this conversion method, all information in the original TCP message is losslessly migrated to the HTTP protocol framework. The downstream business processing layer can rely entirely on the HTTP protocol for subsequent processing without needing to know which protocol the original message arrived through. At the same time, because the original length field and encrypted message body are preserved, the downstream can completely restore the state of the original TCP message for decryption, verification, and business processing. This design enables the system to have a unified internal processing model for the two protocols, laying the technical foundation for subsequent direct support of external social security institutions accessing the HTTP protocol.

[0079] Furthermore, you can also view Figure 5 , Figure 5 This is a detailed process diagram based on step S40 in the first embodiment. Figure 5 The step of instantiating the abstract template class into multiple concrete template subclasses includes S41-43: Step S41: Obtain the business process definitions of all external social security agencies to be connected; Step S42: Perform cluster analysis on the business process definition and group external social security institutions with completely identical business processing step sequences into the same process group; Step S43: Create a concrete template subclass for each process group, so that the concrete template subclass inherits from the abstract template class and overrides the implementation of steps in the standard processing flow that are related to the personalized requirements of the process group; Step S44: For the remaining external social security institutions that are not classified into any special group, a common concrete template subclass is instantiated. The common concrete template subclass directly reuses the default processing logic defined in the abstract template class.

[0080] In this embodiment, the process of instantiating an abstract template class into multiple concrete template subclasses is essentially based on cluster analysis of business processes. Organizations with the same processing logic from over thirty provinces are grouped together, with only one concrete template subclass created for each group. This reduces the amount of code that needs to be maintained from over thirty to just two or three. The specific implementation methods for each step are described in detail below.

[0081] Obtain the business process definitions of all external social security agencies to be integrated. In the initial project phase, the development team needs to collect the technical interface documents for each external social security agency. These documents detail the agency's unique business processing rules. For example, some agencies require validation of field A before field B, some require calling an external service to obtain supplementary data before field conversion, and some fully follow standard processes. These business process definitions can be requirements specifications recorded in text or code logic already implemented in existing independent pre-processing programs. The development team organizes these scattered process definitions into a structured description file, such as using an Excel spreadsheet to list the processing steps included in each interface for each agency. For the more than thirty pre-processing programs already online, the development team can extract the core processing flow of each program through code review and reverse engineering, marking which steps are standard and which are customized. Although this step is done manually, its results directly determine the accuracy of subsequent grouping.

[0082] Cluster analysis was performed on the above business process definitions to group external social security agencies with identical business processing step sequences into the same process group. Cluster analysis can be performed manually or semi-automatically. Since there are approximately thirty agencies, manually comparing the process descriptions of each agency is feasible. In practice, analysts write out the processing step sequence for each agency, for example, "decryption → parsing → format validation → general business validation → standard field conversion → forwarding → encryption," and then group agencies with identical sequences together. After reviewing over thirty provinces in the actual production environment, it was found that most provinces have completely identical processes and can be grouped into a common group; Jiangxi Province has an additional third-party data validation step in its processing, therefore it is grouped separately; Jiangsu Province has special mapping requirements in the field conversion stage, therefore it is grouped separately. This resulted in three groups in total. During the clustering process, analysts need to pay special attention to groups with only minor differences, such as differences only in the threshold of a certain validation rule. Such differences can be disregarded as grouping criteria and addressed through subsequent strategy classes, thus avoiding the creation of excessive template subclasses. Only those mechanisms that differ significantly in the existence, sequence, or overall logic of their steps need to be grouped separately.

[0083] Create a concrete template subclass for each process group, allowing this subclass to inherit from the abstract template class and override the steps in the standard processing flow that are relevant to the group's specific needs. For example, for the common group, create a subclass named CommonProcessTemplate, which inherits from the abstract template class BaseProcessTemplate but does not override any methods, fully reusing the parent class's default implementation. For the Jiangxi group, create a JiangxiProcessTemplate subclass, overriding the business validation methods to add a Jiangxi-specific operation of calling remote services for data comparison. For the Jiangsu group, create a JiangsuProcessTemplate subclass, overriding the field conversion methods to perform conversions according to Jiangsu's field mapping table. When overriding, the subclass can call the parent class's default implementation using the super keyword, and then add or modify logic on top of it. This ensures both the reusability of common processes and the fulfillment of personalized requirements.

[0084] For the remaining external social security agencies not grouped into any special group, a common concrete template subclass is instantiated uniformly. This common concrete template subclass directly reuses the default processing logic defined in the abstract template class. In this embodiment, the above clustering analysis categorizes most agencies into a common group, so they all use instances of CommonProcessTemplate. At system startup, the agency-template mapping table in the configuration file or database records the template subclass name corresponding to each agency code. For 28 of the 30 provinces, including Beijing, Shanghai, and Guangzhou, the mapping table records CommonProcessTemplate; for Jiangxi Province, it records JiangxiProcessTemplate; and for Jiangsu Province, it records JiangsuProcessTemplate. When the system runs, a singleton instance of the corresponding template subclass is created based on the agency identifier using reflection or the factory pattern. Since the common concrete template subclass does not contain any personalized code, its maintenance cost is extremely low; and the two special template subclasses only maintain logic specific to their respective provinces and do not affect other provinces. Through the four steps described above, the development team successfully merged the business logic from over thirty independent pre-processes into just three concrete template subclasses, significantly reducing code redundancy and maintenance costs. When common logic needs modification, only the abstract template class or CommonProcessTemplate needs to be modified, and all twenty-eight provinces using that template will automatically benefit; when logic specific to Jiangxi needs modification, only JiangxiProcessTemplate needs to be modified, and other provinces remain unaffected. This grouping and instantiation scheme is one of the core innovations of this invention, making the integration of large-scale, multi-source, heterogeneous systems possible.

[0085] Furthermore, you can also view Figure 6 , Figure 6 This is a detailed process diagram based on step S50 in the first embodiment. Figure 6 The step of determining the corresponding strategy class based on the interface identifier includes S51~52: Step S51: Pass the interface identifier as an input parameter to the preset policy factory; Step S52: Dynamically find and return the corresponding strategy class instance through the strategy factory. The strategy factory registers the mapping relationship between each interface identifier and the strategy class instance.

[0086] In this embodiment, the operation of determining the corresponding strategy class based on the interface identifier is based on the introduction of a strategy factory object. This object centrally manages the mapping relationship between interface identifiers and strategy class instances. At runtime, the factory dynamically looks up and returns the corresponding strategy class, thereby enabling on-demand loading of personalized logic at the interface level. This design avoids writing a large number of conditional branch statements in template subclasses and eliminates the need to write routing code separately for each interface, resulting in good extensibility and maintainability.

[0087] The aforementioned interface identifier is passed as an input parameter to the pre-defined strategy factory. When the business processing layer starts, a strategy factory instance is already created, typically using a singleton pattern to ensure global uniqueness. This strategy factory internally maintains a core data structure: a mapping table between interface identifiers and strategy class instances. This mapping table can be implemented using a Java ConcurrentHashMap, where the keys are string-type interface identifiers and the values ​​are strategy class instances that implement the unified strategy interface. Once the interface identifier is obtained, such as the string "QUERY_BALANCE" parsed from a URL, the system uses this string as a parameter to call the lookup method provided by the strategy factory, such as "Strategy findStrategy(String apiCode)". The strategy factory's method does not perform any complex business calculations; it only retrieves the corresponding value from the mapping table based on the passed key. To ensure performance in high-concurrency scenarios, the mapping table is read-only after initialization, thus requiring no locking and resulting in extremely high read efficiency. Meanwhile, the strategy factory also provides a registration method that allows new strategy class instances to be added to the mapping table at system startup or during operation. However, this dynamic registration is usually only used in hot deployment scenarios. In general, all strategy classes are registered once during system startup.

[0088] The strategy factory dynamically finds and returns corresponding strategy class instances, registering a mapping between interface identifiers and strategy class instances. In practice, the strategy factory initializes during the startup phase of the Spring container or a custom loader. It scans all strategy classes under the specified package path, all annotated with custom annotations, such as `@ApiStrategy(apiCode = "QUERY_BALANCE")`. After scanning, the system creates an instance of each strategy class using reflection and stores the interface identifier declared in the annotation along with the instance in the mapping table. For strategy classes without annotations, mappings can also be declared through a configuration file, which is read at startup to complete the registration.

[0089] When an interface identifier is passed in, the strategy factory performs a lookup in the mapping table. If the lookup is successful, meaning the entry corresponding to the interface identifier exists in the mapping table, a strategy class instance is immediately returned. For example, if "QUERY_BALANCE" is passed in, the factory returns an instance of BjQueryBalanceStrategy. This instance is usually a singleton, stateless, and can be safely shared by multiple request threads. If the lookup fails, meaning the interface identifier does not exist in the mapping table, the strategy factory does not directly return a null value or throw an exception, but instead employs a fallback strategy. There are two common fallback strategies: one is to return a default strategy class instance, which implements the most general processing logic and is applicable to most interfaces; the other is to throw an explicit exception, indicating that no corresponding strategy was found, which is then caught and handled by the upper-level caller. This embodiment uses the default strategy approach, meaning the strategy factory internally maintains a default strategy instance, which is returned when an exact match fails. The default strategy class implements general behaviors that do not require any personalized logic in the standard process, such as directly mapping fields without additional processing. In this way, even if an interface does not explicitly configure a strategy class, the system can still work normally in the default manner, avoiding request failures due to missed configurations.

[0090] The strategy factory design offers two significant advantages. First, strategy class lookup and usage are completely decoupled. Template subclasses don't need to know which specific strategy classes exist; they simply retrieve them from the factory. When adding customized logic to an interface, developers only need to write a new strategy class and register it with the factory, without modifying any existing template subclasses or factory code, adhering to the open / closed principle. Second, the strategy factory can be integrated with a configuration center to achieve runtime hot-switching of strategies. For example, by modifying the mapping relationships in the configuration file, the strategy class corresponding to a specific interface can be replaced online with the new version without restarting the entire application. This is extremely useful for emergency bug fixes or A / B testing in production environments.

[0091] In this embodiment, the corresponding strategy class instance is obtained quickly and accurately based on the interface identifier. This instance will be embedded into the standard processing flow of the specific template subclass orchestration to perform interface-level personalized validation, conversion, and other logic. The entire strategy lookup process has low time complexity and does not involve databases or remote calls, ensuring high throughput and low latency of the integration method.

[0092] Furthermore, you can also view Figure 7 , Figure 7 This is a flowchart illustrating the second embodiment of the method for connecting with external social security institutions according to the present invention. Figure 7 After the step of embedding the strategy class into the standard processing flow arranged by the specific template subclass, the process further includes steps S70-80: Step S70: When an exception occurs during the execution of the strategy class, the exception is captured and logged. Step S80: Based on the pre-configured exception handling strategy, decide whether to retry, skip the current interface call, return a preset error code to the external social security agency, or report the exception to the occupational pension system's monitoring platform.

[0093] In this embodiment, after the strategy class is embedded into the standard processing flow arranged by the specific template subclass and executed, it is also necessary to uniformly handle any exceptions that may occur during the execution process. This embodiment defines a complete exception handling mechanism that can capture exceptions thrown by any link in the strategy class or standard processing flow, and determine subsequent behavior according to the pre-configured strategy, thereby ensuring the stability and reliability of the interface system and avoiding the unavailability of the entire service due to temporary failures of individual interfaces or data anomalies.

[0094] When an exception occurs during the execution of the aforementioned strategy class, the exception is caught and logged. In the standard processing flow, the specific template subclass wraps the entire call to the strategy class's method within a try-catch block. The strategy class may throw a variety of exceptions, such as decryption exceptions indicating incorrect encryption algorithms or keys, parsing exceptions indicating unexpected message formats, validation exceptions indicating business data not meeting rules, network exceptions indicating the downstream occupational pension system is unreachable, timeout exceptions indicating response time exceeding thresholds, and runtime exceptions such as null pointer exceptions and array out-of-bounds errors. Regardless of the type, all exceptions are caught by the exception handler in the template subclass. After catching an exception, logging is performed immediately. Logging uses a structured logging framework, such as Log4j2 or SLF4J, and outputs logs according to a fixed format. The log content should include at least the following information: a unique tracking ID for the request, which is typically generated and runs throughout the entire call chain; the organization identifier of the external social security agency where the exception occurred, such as "BJ1001"; the identifier of the interface where the call failed, such as "QUERY_BALANCE"; the specific steps or strategy class name where the exception occurred; the first few lines of the exception stack trace to help locate the code; and key summary information of the request message, but sensitive data should be anonymized. The logs will be output to both a local file and a remote log center, such as the ELK stack or Alibaba Cloud Log Service, facilitating real-time monitoring and post-event analysis by operations and maintenance personnel. In addition to logging, anomaly indicators can be collected, and anomaly counts can be sent to monitoring systems such as Prometheus. An alarm will be triggered when the number of anomalies exceeds a threshold within a unit of time.

[0095] Based on the pre-configured exception handling strategy, the system decides whether to retry, skip the current interface call, return a preset error code to the external social security agency, or report the exception to the occupational pension system's monitoring platform. Different exception types and different business scenarios require differentiated handling methods; therefore, this embodiment introduces a configurable exception handling strategy component. This component maintains an exception handling strategy configuration table for each institution or each interface, recording the handling actions for different exception types. Configuration can be done through configuration files, database tables, or dynamically distributed from a configuration center. The system loads these configurations at startup and, during runtime, matches the currently occurring exception type with the current institution and interface identifiers to select the most appropriate handling action. Specific handling actions include the following:

[0096] The first processing action is retrying. For recoverable exceptions such as network timeouts, database connection interruptions, and temporary busy downstream services, the system can automatically initiate retries. The number of retries and the retry interval are configurable; for example, a maximum of 3 retries with a 500-millisecond interval between each. When retries, idempotency must be ensured, meaning that the same request executed multiple times should produce the same result, without data duplication or status errors. Query interfaces are inherently idempotent and can be retried directly; for write operation interfaces such as payment and change requests, the business logic must guarantee idempotency, or the caller must include a unique serial number in the message to avoid duplicate processing. If all retries fail, the system will continue processing according to other actions.

[0097] The second approach is to skip the current API call. This is suitable for exceptions in optional functional interfaces or non-critical business paths. For example, the failure of an interface used to report statistical data should not affect the main business process. After configuring the skip strategy, the system will ignore the exception when it is caught and continue to execute subsequent steps in the standard processing flow, or directly return a default success response to the external social security agency. The skip strategy should be used with caution and should only be enabled in scenarios where the loss of this call is acceptable or where service degradation is permissible.

[0098] The third processing action is to return a preset error code to the external social security agency. This is the most common exception handling method, applicable to most business verification exceptions, permission exceptions, and internal system processing failures. The system maps different exception types to different error codes; for example, decryption failure is mapped to error code "1001", message format error is mapped to "1002", and business verification failure is mapped to "2001". These error codes, along with error description information, are encapsulated into a response message, encrypted and assembled according to the encryption method and message format required by the agency, and then returned to the external social security agency. In this way, the external social security agency can clearly understand the reason for the request being rejected and can correct or retry accordingly.

[0099] The fourth action is to report the anomaly to the occupational pension system's monitoring platform. This approach is typically used in conjunction with the three actions mentioned above; that is, while performing a retrieval or returning an error code, the anomaly information is reported to the monitoring platform. The reported content includes a summary of the anomaly, the time of occurrence, and key information such as the business data involved. After receiving the report, the monitoring platform can perform statistics, analysis, and alerts. For serious anomalies, such as decryption key failure or core policy class loading failure, the system can trigger real-time alerts, notifying on-duty personnel via SMS, DingTalk, or telephone for emergency intervention.

[0100] Through this process, a comprehensive closed-loop anomaly handling mechanism has been established. This mechanism can automatically handle recoverable temporary faults, reducing manual intervention, while clearly reporting anomalies that cannot be automatically handled to the caller and operations personnel, preventing fault propagation and difficulties in fault localization. Especially in complex scenarios involving more than 30 external social security institutions, where different institutions have varying network quality, data quality, and business logic, a unified anomaly handling mechanism is a crucial cornerstone for ensuring overall service quality.

[0101] Furthermore, regarding the implementation of the connection method with external social security institutions as described above, its system architecture diagram can be viewed. Figure 8 , Figure 8 This is a system architecture diagram based on a network-connected solution. Figure 8 In the new system architecture presented, the entire external agency integration process is divided into three core layers: the TCP gateway layer, the human resources and social security front-end layer, and the occupational pension system layer. The TCP gateway layer is responsible for establishing physical connections with external social security institutions and completing protocol conversions; the human resources and social security front-end layer handles the orchestration and execution of business logic; and the occupational pension system layer provides core entrusted business processing capabilities. These three layers communicate via the standard HTTP protocol, completely decoupling the underlying TCP communication details from the upper-layer business logic. The following section analyzes the data processing flow under this architecture in detail, following the order of message reception and return.

[0102] First, the TCP gateway layer pre-opens multiple TCP listening ports during startup, such as ports 10001 to 10030. Each port establishes a static one-to-one binding relationship with the code of an external social security organization through a local configuration file. When the external social security organization sends a TCP packet via a dedicated line, the packet passes through network devices such as routers and firewalls before finally reaching the server where the TCP gateway resides. The operating system distributes the packet to the corresponding listening port based on the destination port number in the TCP packet header. After receiving the complete packet, the Netty server in the gateway layer immediately queries the mapping table based on the destination port of the packet to obtain the organization identifier to which the request belongs. Since the packet body is still encrypted at this time, the gateway layer does not attempt to decrypt or parse the packet content. It only does three things: extracts the destination port number to determine the organization identifier, extracts the encrypted packet body and length field from the TCP packet, and constructs a new HTTP request. When constructing the HTTP request, the gateway layer appends the aforementioned organization identifier to the URL as a query parameter, for example, expanding the original request path " / forward" to " / forward?orgCode=BJ1001". Simultaneously, the gateway layer adds the interface identifier parsed from the TCP packet to the URL, or temporarily leaves it as an empty string, awaiting supplementation in subsequent steps. Then, the gateway layer uses the encrypted packet body as the message body of the HTTP request, sets the Content-Type to binary stream, and adds information such as the original length field to the HTTP header. After completing the HTTP request construction, the gateway layer forwards it to the front-end layer via an HTTP client. The forwarding target address can be the local loopback address or the IP port of a remote service.

[0103] Secondly, after receiving the aforementioned HTTP request, the human resources and social security front-end layer extracts the organization identifier from the URL and needs to obtain the interface identifier. Since the gateway layer may not have yet parsed the interface identifier, the front-end layer first obtains the corresponding decryption key based on the organization identifier, decrypts the encrypted message body into plaintext fields, and then extracts the interface identifier from the plaintext fields according to preset rules. Subsequently, the front-end layer uses the organization identifier to select the corresponding specific template subclass and uses the interface identifier to obtain the corresponding strategy class through the strategy factory. The human resources and social security front-end layer embeds the strategy class into the standard processing flow defined in the template subclass, executing seven steps sequentially: message decryption, field parsing, format validation, business validation, field conversion, forwarding to the occupational pension system, and response encryption. Throughout the entire process, the front-end layer is completely unaware of whether the original message arrived via TCP or HTTP protocol, relying only on the organization identifier, interface identifier, and message body content carried in the HTTP request.

[0104] Finally, the front-end layer forwards the converted standard format message to the occupational pension system. After processing the business request, the occupational pension system returns a plaintext response. The front-end layer obtains the corresponding encryption algorithm based on the institution identifier, encrypts the response, and then returns the encrypted response to the TCP gateway layer via the HTTP protocol. The gateway layer then writes the response back to the corresponding TCP connection and finally delivers it to the external social security institution. Figure 8 The architecture shown separates protocol conversion from business logic by introducing an independent TCP gateway. This allows for smooth protocol expansion if HTTP protocol access is required in the future. Simply add an HTTP listening port to the gateway layer and forward HTTP requests directly to the human resources and social security front-end layer without modifying any business processing code.

[0105] Furthermore, based on the data analysis conducted by the aforementioned external social security agencies, a template class was implemented. This process can be viewed... Figure 9 , Figure 9 The flowchart illustrating the implementation of the template class demonstrates how a specific template subclass holds multiple strategy classes through aggregation relationships, and how it dynamically locates the correct processing unit at runtime based on the organization identifier and interface identifier. Based on the logic of this class diagram, when the system receives a request from an external social security organization, it will complete the collaborative invocation between the template subclass and the strategy class according to the following steps.

[0106] First, the organization identifier is extracted from the URL of the HTTP request, for example, "BJ1001". The system maintains a global organization template mapping table, which stores the specific template subclass instance corresponding to the organization, using the organization code as the key. Since most organizations use a common template subclass, most entries in the mapping table point to the same CommonProcessTemplate singleton; only the entries for Jiangxi Province and Jiangsu Province point to JiangxiProcessTemplate and JiangsuProcessTemplate, respectively. The system uses the organization identifier to look up the specific template subclass instance that should be used for the current request in the mapping table, for example, finding CommonProcessTemplate.

[0107] Secondly, the system extracts the interface identifier from the HTTP request URL, such as "QUERY_BALANCE". Each specific template subclass holds a strategy factory, which is essentially a mapping table from interface identifiers to strategy class instances. The content of the strategy factories held by different template subclasses differs: the strategy factory in CommonProcessTemplate registers strategy classes corresponding to all interfaces common to 28 provinces, for example, "QUERY_BALANCE" maps to DefaultQueryBalanceStrategy, and "PAY" maps to DefaultPayStrategy; the strategy factory in JiangxiProcessTemplate, in addition to registering strategies common to Jiangxi, may also override some Jiangxi-specific strategies for certain interfaces, for example, "QUERY_BALANCE" maps to JiangxiQueryBalanceStrategy; the same applies to JiangsuProcessTemplate. The system passes the interface identifier as a parameter to the strategy factory within the current template subclass, and the factory returns the specific strategy class instance after looking it up.

[0108] Finally, the specific template subclass begins executing its template methods. These methods call each processing step in a fixed order, such as message decryption and field parsing. When a step requiring customized processing is reached, such as business validation or field conversion, the template subclass checks if a strategy class is configured for that step. If the strategy class exists and implements the hook method for that step, the template subclass delegates control to the corresponding method in the strategy class; otherwise, the template subclass executes its own default implementation. Figure 9 The association lines between specific template subclasses and strategy classes represent this aggregation relationship—a template subclass can be associated with zero, one, or more strategy classes. Through this design, common processes are solidified in the template subclasses, while individual logic is independent in the strategy classes, and the two are dynamically combined through association, avoiding the maintenance burden of writing independent code for each province and each interface. After all steps are executed, the result is returned along the original path. Figure 9 The class diagram logic supports the core mechanism for merging business logic in the entire docking method.

[0109] It should be noted that the above examples are only for understanding this application and do not constitute a limitation on the connection method of external social security institutions. Any simple modifications based on this technical concept are within the scope of protection of this application.

[0110] This application provides a docking device for an external social security agency. The docking device for the external social security agency includes: at least one processor; and a memory communicatively connected to the at least one processor; wherein the memory stores instructions executable by the at least one processor, and the instructions are executed by the at least one processor to enable the at least one processor to execute the docking method for the external social security agency in the above embodiment 1.

[0111] The following is for reference. Figure 10 The diagram illustrates a structural schematic of a docking device suitable for implementing embodiments of this application. The docking device for the external social security agency in these embodiments may include, but is not limited to, mobile terminals such as mobile phones, laptops, digital radio receivers, PDAs (Personal Digital Assistants), PADs (Portable Application Description), etc., and fixed terminals such as digital TVs, desktop computers, etc. Figure 10 The external social security agency docking equipment shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0112] like Figure 10 As shown, the interface device for the external social security agency may include a processing unit 1001 (e.g., a central processing unit, a graphics processing unit, etc.), which can perform various appropriate actions and processes according to a program stored in a read-only memory (ROM) 1002 or a program loaded from a storage device 1003 into a random access memory (RAM) 1004. The RAM 1004 also stores various programs and data required for the operation of the interface device for the external social security agency. The processing unit 1001, ROM 1002, and RAM 1004 are interconnected via a bus 1005. An input / output (I / O) interface 1006 is also connected to the bus. Typically, the following can be connected to I / O interface 1006: input devices 1007 including, for example, touchscreens, touchpads, keyboards, mice, image sensors, microphones, accelerometers, gyroscopes, etc.; output devices 1008 including, for example, liquid crystal displays (LCDs), speakers, vibrators, etc.; storage devices 1003 including, for example, magnetic tapes, hard disks, etc.; and communication devices 1009. Communication device 1009 allows the docking device of an external social security agency to communicate wirelessly or wiredly with other devices to exchange data. Although docking devices with various external social security agencies are shown in the figure, it should be understood that it is not required to implement or possess all of them. More or fewer may be implemented alternatively.

[0113] Specifically, according to the embodiments disclosed in this application, the processes described above with reference to the flowcharts can be implemented as computer software programs. For example, embodiments disclosed in this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via a communication device, or installed from storage device 1003, or installed from ROM 1002. When the computer program is executed by processing device 1001, it performs the functions defined in the methods of the embodiments disclosed in this application.

[0114] The external social security agency docking equipment provided in this application, employing the external social security agency docking method described in the above embodiments, can solve the technical problem of high resource consumption and high maintenance costs caused by the inability to merge multiple independent front-end programs in the existing occupational pension trustee operation system. Compared with the prior art, the beneficial effects of the external social security agency docking equipment provided in this application are the same as those of the external social security agency docking method provided in the above embodiments, and other technical features of the external social security agency docking equipment are the same as those disclosed in the previous embodiment method, and will not be repeated here.

[0115] It should be understood that the various parts disclosed in this application can be implemented using hardware, software, firmware, or a combination thereof. In the description of the above embodiments, specific features, structures, materials, or characteristics can be combined in any suitable manner in one or more embodiments or examples.

[0116] 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.

[0117] This application provides a storage medium, which is a computer-readable storage medium having computer-readable program instructions (i.e., a computer program) stored thereon, which are used to execute the external social security agency docking method in the above embodiments.

[0118] The computer-readable storage medium provided in this application may be, for example, a USB flash drive, but is not limited to electrical, magnetic, optical, electromagnetic, infrared, or semiconductor devices, or any combination thereof. More specific examples of computer-readable storage media may include, but are not limited to: electrical connections having one or more wires, portable computer disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM), or flash memory, optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof. In this embodiment, the computer-readable storage medium may be any tangible medium containing or storing a program that can be executed by instructions, used by devices, or used in conjunction with them. The program code contained on the computer-readable storage medium may be transmitted using any suitable medium, including but not limited to: wires, optical cables, RF (Radio Frequency), etc., or any suitable combination thereof.

[0119] The aforementioned computer-readable storage medium may be included in the docking equipment of the external social security agency; or it may exist independently and not be installed in the docking equipment of the external social security agency.

[0120] The aforementioned computer-readable storage medium carries one or more programs. When the aforementioned one or more programs are executed by the docking device of the external social security agency, the docking device of the external social security agency implements the technical content of the docking method embodiment of the external social security agency as shown above.

[0121] Computer program code for performing the operations of this application can be written in one or more programming languages ​​or a combination thereof, including object-oriented programming languages ​​such as Java, Smalltalk, and C++, as well as conventional procedural programming languages ​​such as "C" or similar programming languages. The program code can be executed entirely on the user's computer, partially on the user's computer, as a standalone software package, partially on the user's computer and partially on a remote computer, or entirely on a remote computer or server. In cases involving remote computers, the remote computer can be connected to the user's computer via any type of network—including a local area network (LAN) or a wide area network (WAN)—or can be connected to an external computer (e.g., via the Internet using an Internet service provider).

[0122] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of methods and computer program products according to various embodiments of this application. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of code containing one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutively indicated blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, can be implemented using dedicated hardware-based implementations that perform the specified functions or operations, or can be implemented using a combination of dedicated hardware and computer instructions.

[0123] The modules described in the embodiments of this application can be implemented in software or hardware. The names of the modules do not necessarily limit the functionality of the unit itself.

[0124] The readable storage medium provided in this application is a computer-readable storage medium that stores computer-readable program instructions (i.e., computer programs) for executing the aforementioned docking method with external social security institutions. This solves the technical problem of high resource consumption and high maintenance costs caused by the inability to merge multiple independent front-end programs in existing occupational pension entrusted operation systems. Compared with the prior art, the beneficial effects of the computer-readable storage medium provided in this application are the same as those of the docking method with external social security institutions provided in the above embodiments, and will not be elaborated upon here.< / request>

Claims

1. A method for connecting with external social security agencies, characterized in that, The method for connecting with external social security agencies includes the following steps: TCP packets are received through multiple pre-opened TCP listening ports, each of which corresponds to a unique external social security agency; Based on the target TCP listening port reached by the TCP packet, determine the organization identifier of the external social security agency that sent the TCP packet, and parse the interface identifier from the TCP packet; The received TCP packet is converted into an HTTP request, and the organization identifier and the interface identifier are added to the URL of the HTTP request; Forward the HTTP request, wherein an abstract template class and multiple strategy classes are predefined; the abstract template class is instantiated into multiple concrete template subclasses, each concrete template subclass corresponds to at least one common business process of an external social security institution, and each concrete template subclass is associated with one or more of the strategy classes, the strategy classes being used to implement the personalized processing logic of the target interface; The specific template subclass is determined based on the organization identifier in the URL, and the corresponding strategy class is determined based on the interface identifier; The strategy class is embedded into the standard processing flow arranged by the specific template subclass and executed to complete the message processing for the external social security agency.

2. The method for connecting with external social security institutions as described in claim 1, characterized in that, The step of instantiating the abstract template class into multiple concrete template subclasses includes: Obtain the business process definitions of all external social security agencies to be connected; Cluster analysis was performed on the business process definition to group external social security agencies with completely identical business processing step sequences into the same process group; Create a concrete template subclass for each process group, so that the concrete template subclass inherits from the abstract template class and overrides the implementation of the steps in the standard processing flow that are related to the personalized requirements of the process group; For other external social security institutions that are not classified into any special group, a common concrete template subclass is instantiated. The common concrete template subclass directly reuses the default processing logic defined in the abstract template class.

3. The method for connecting with external social security institutions as described in claim 1, characterized in that, The step of determining the organization identifier of the external social security agency that sent the TCP packet based on the target TCP listening port to which the TCP packet arrived includes: Read the locally pre-configured port and agency code mapping table, which records the correspondence between each TCP listening port number and the external social security agency code; The destination port number of the TCP packet is used as the key value to match the corresponding organization code in the mapping table, which is then used as the organization identifier.

4. The method for connecting with external social security institutions as described in claim 1, characterized in that, The step of parsing the interface identifier from the TCP packet includes: Obtain the corresponding message decryption key based on the organization identifier, decrypt the encrypted message body in the TCP message, and obtain the plaintext field; Extract the interface code field with a preset position or preset label from the plaintext field and use it as the interface identifier.

5. The method for connecting with external social security institutions as described in claim 1, characterized in that, The step of converting the received TCP packet into an HTTP request includes: Use the original message body in the TCP packet as the message body of the HTTP request, and set the content type of the HTTP request to encrypted binary stream or text type; The HTTP request is formed by adding the original length field information of the TCP segment to the header of the HTTP request.

6. The method for connecting with external social security institutions as described in claim 1, characterized in that, The standard processing procedure includes the following steps: The corresponding decryption algorithm is invoked based on the organization identifier to decrypt the message in the HTTP request and obtain the message field; The message fields are parsed to extract business parameter fields. The extracted business parameter fields are then format-validated to determine whether the field type, length, and value range conform to preset rules. The business parameter fields that pass the verification are then subjected to business validity verification, which includes checking whether the organization code is valid, the interface call permissions, and the message sequence. Based on the field standards of the downstream occupational pension system, the verified business parameter fields are converted into messages in the format required by the downstream system. The converted message is forwarded to the core business interface of the occupational pension trustee operation system. The system receives the response message returned by the downstream system, encrypts the response message by calling the corresponding encryption algorithm according to the institution identifier, and then returns the response to the external social security institution that sent the request.

7. The method for connecting with external social security institutions as described in claim 1, characterized in that, The step of determining the corresponding strategy class based on the interface identifier includes: The interface identifier is passed as an input parameter to the preset policy factory; The strategy factory dynamically searches for and returns the corresponding strategy class instance. The strategy factory registers the mapping relationship between each interface identifier and the strategy class instance.

8. The method for connecting with external social security institutions as described in claim 1, characterized in that, After the step of embedding the strategy class into the standard processing flow arranged by the specific template subclass, the method further includes: When an exception occurs during the execution of the strategy class, the exception is captured and logged; Based on the pre-configured exception handling strategy, it is determined whether to retry, skip the current interface call, return a preset error code to the external social security agency, or report the exception to the occupational pension system's monitoring platform.

9. A device for connecting to an external social security agency, characterized in that, The external social security agency's docking device stores a computer program, which, when executed by a processor, implements the docking method for external social security agencies as described in any one of claims 1-8.

10. A storage medium, characterized in that, The storage medium stores a computer program, which, when executed by a processor, implements the method for connecting with external social security agencies as described in any one of claims 1-8.

Images