A multi-protocol adaptation heterogeneous signing platform unified management method and system

Abstract

This application discloses a unified management method and system for heterogeneous signing platforms with multi-protocol adaptation. The method includes: receiving signing requests through a unified signing interface and determining the target signing platform type according to a routing strategy; calling the corresponding adapter from multiple platform adapters registered in a pluggable manner according to the target signing platform type; converting standardized request parameters into the calling format and authentication method of the target platform's native interface and initiating a signing task by calling its API; mapping standardized signing capabilities to the signing capabilities actually supported by the target platform; using a dual-channel mechanism combining active query and passive callback to synchronize the signing status of the target platform to a unified state machine in real time; and converting the signed document and evidence chain returned by the target platform into a unified format and sending it back to the core service layer for archiving. Implementing the embodiments of this application can achieve unified access, scheduling, and management of multiple heterogeneous signing platforms, reducing the technical complexity of multi-platform integration.

Description

[0001] Technical Field This application relates to the field of electronic digital data technology, specifically to a unified management method and system for heterogeneous signing platforms with multi-protocol adaptation, electronic devices, and computer-readable storage media. Background Technology

[0002] As enterprises deepen their digital transformation, electronic contract signing has become an important part of enterprise operations. Enterprises often face the situation of multiple electronic signing platforms coexisting: on the one hand, some large enterprises have developed their own internal signing systems to meet the need for independent control. On the other hand, to adapt to the signing habits of external partners, enterprises also need to connect to third-party signing platforms such as E-Sign, Fadada, and Shangshangqian. Existing technologies have the following technical problems in managing multiple signing platforms: The interface protocols, data formats, and authentication methods of each signing platform are different, requiring enterprises to develop separate integration programs for each platform, resulting in high system complexity and maintenance costs. When it is necessary to replace or add a signing platform, adaptation code must be redeveloped, leading to poor scalability. Furthermore, the signing status definitions and status synchronization mechanisms of each platform are inconsistent, making it difficult for enterprises to uniformly track the status and manage the process of signing tasks across multiple platforms. Different platforms have varying levels of support for signature types, signing methods, and identity authentication capabilities, lacking a unified capability abstraction layer. Business systems need to write differentiated calling logic for different platforms. When third-party partners need to access contract signing services, existing solutions lack standardized access gateways, resulting in long access cycles, high customization requirements, and difficulty in ensuring data isolation. Therefore, how to achieve unified access, scheduling and management of multiple heterogeneous signing platforms and reduce the technical complexity of multi-platform integration has become a technical problem to be solved in this field.

[0003] In order to solve the problems existing in the prior art, the present application aims to provide a unified management method and system for heterogeneous signing platforms with multi-protocol adaptation, which can realize unified access, scheduling and management of multiple heterogeneous signing platforms and reduce the technical complexity of multi-platform integration.

[0004] This application provides a unified management method for heterogeneous signing platforms with multi-protocol adaptation, including: S101. Receive signing requests through the unified signing interface and determine the target signing platform type according to the routing policy; S102. Based on the target signing platform type, call the corresponding adapter from the multiple platform adapters registered in plug-in mode; S103. Convert the standardized request parameters into the calling format and authentication method of the target platform's native interface, and call its API to initiate a signing task; S104. When initiating a signing task, the standardized signing capabilities are mapped to the signing capabilities actually supported by the target platform. The signing capabilities include the mapping of signing stamp type, identity authentication method, and signing order mode. S105. After completing the signing capability mapping and initiating the signing task, a dual-channel mechanism combining active query and passive callback is adopted to synchronize the signing status of the target platform to the unified state machine in real time. S106. After signing, convert the signed documents and evidence chain returned by the target platform into a unified format and send them back to the core service layer for archiving.

[0005] Further, S101 includes: The signing request data is obtained through a unified interface, and the source identifier is obtained by parsing the signing request data. Match the pre-defined routing policy database based on the parsed source identifier; If the specified routing conditions are met, the target platform type is determined directly; if not, intelligent routing logic is used to determine the target platform type based on platform load. If the platform load exceeds the preset threshold, switch to the backup platform type and trigger a degraded route.

[0006] Furthermore, following S102, the following is also included: Adjust the data format of the target platform's communication protocol to obtain the converted protocol data packets; Parse the functional requirements in the protocol data packet. If they are inconsistent with the functional support of the target platform, adjust the calling logic and determine the mapped functional instructions. Based on the mapped function instructions, collect the status data of the target platform and verify the instruction execution conditions; If the conditions are met, the execution instructions for the function instructions are generated, and the execution instructions are obtained and issued.

[0007] Further, S105 includes: Establish an active query channel to periodically send status retrieval requests to the target platform to obtain the latest status data; Simultaneously, it receives status change notification messages pushed by the platform through a passive callback channel; The latest status data obtained through active query is compared with the changed status information from the passive callback channel to identify consistent status records. The status records are written into a preset status library to complete the real-time capture of the status.

[0008] Further, S106 includes: Obtain signed documents and evidence chains from the target platform, perform preliminary data analysis, and obtain structured raw data records; The original data records are standardized, and data files conforming to the specifications are generated according to unified format rules; The transmission process is initiated, and it is determined whether the transmission path complies with security rules. If it does, the data file is transferred to the core service layer. The core service layer classifies and stores the received data file to determine the storage location and generate a queryable archive index.

[0009] This application also provides a unified management system for heterogeneous signing platforms that adapt to multiple protocols, including: The platform type determination module is used to receive signing requests through the unified signing interface and determine the target signing platform type based on the routing strategy. The adapter invocation module is used to invoke the corresponding adapter from multiple pluggable platform adapters based on the target signing platform type; The mapping module is used to map standardized signing capabilities to the actual signing capabilities supported by the target platform when initiating a signing task. The signing capabilities include signing stamp type mapping, identity authentication method mapping, and signing order mode mapping. The state synchronization module is used to synchronize the signing status of the target platform to the unified state machine in real time after completing the signing capability mapping and initiating the signing task, using a dual-channel mechanism that combines active query and passive callback. The unified archiving module is used to convert the signed documents and evidence chains returned by the target platform into a unified format after signing, and then send them back to the core service layer to complete archiving.

[0010] In this embodiment, a unified access management system for the self-developed signing platform and multiple third-party signing platforms is achieved by constructing a unified signing interface and a multi-protocol adapter architecture. Each adapter adopts a three-layer structure of protocol conversion, capability mapping and state synchronization, which encapsulates the differentiated interfaces of heterogeneous platforms into a unified standardized call interface. The business system does not need to be aware of the specific implementation of the underlying platform, which significantly reduces the system complexity and maintenance cost of multi-platform integration. The plug-in adapter registration mechanism supports rapid expansion and access to new signing platforms. When a new signing platform needs to be added, only the corresponding adapter plugin needs to be developed and registered according to the adapter specification. No modification to the core business code is required, which has good scalability and openness. Through a policy-based routing mechanism, the signing platform can be flexibly scheduled and highly available. It supports multiple modes such as designated platform routing, intelligent routing, and degraded routing. The optimal signing platform can be dynamically selected based on business needs, the platform already certified by the signer, platform availability, and other conditions, thereby improving the flexibility and reliability of system scheduling. Through a unified state synchronization mechanism, the differentiated signing states of various platforms, including both active query and passive callback channels, are transformed into a unified state machine model for unified tracking and management of the entire lifecycle of cross-platform signing tasks. Through standardized access gateways, we provide third-party partners with unified access authentication, access control, interface routing, and data isolation capabilities, enabling them to achieve standardized, low-cost, secure, and controllable access. Attached Figure Description

[0011] Figure 1 This application describes a unified management method for heterogeneous signing platforms with multi-protocol adaptation. Figure 1 ; Figure 2 This application describes a unified management method for heterogeneous signing platforms with multi-protocol adaptation. Figure 2 ; Figure 3 This is a schematic diagram of a unified management system for a heterogeneous signing platform with multi-protocol adaptation as described in this application. Detailed Implementation

[0012] like Figures 1-2 As shown, the unified management method for heterogeneous signing platforms with multi-protocol adaptation described in this application includes: S101. Receive signing requests through the unified signing interface, determine the target signing platform type according to the routing policy, which includes specified platform routing, intelligent routing, and degraded routing.

[0013] Further, in step S101, the signing request data is obtained through a unified interface, and the received data is initially parsed to obtain the basic information of the request and the source identifier; Based on the parsed source identifier, a matching process is performed using a pre-defined routing policy database. If the source identifier matches the specified routing conditions, the corresponding target platform type is directly determined. If the source identifier does not match the specified routing conditions, intelligent routing logic is used to determine the most suitable target platform type through historical data analysis and platform load status. Obtain the platform type information after intelligent routing judgment, compare the type information with the degradation routing rules, and if the platform load exceeds the preset threshold, switch to the backup platform type to obtain the final target platform type; Based on the final determined target platform type, generate the corresponding platform access parameters and interface call instructions to complete the request forwarding preparation; Based on the generated access parameters and invocation instructions, a signing request is forwarded to the target platform, the forwarding log and response status are recorded, and the request processing result is determined. Obtain the response status after forwarding, verify and record the response status. If the response status is abnormal, trigger the backup routing policy and re-determine the target platform type.

[0014] Specifically, in step S101, during the process of receiving a signing request through the unified signing interface and determining the target signing platform type according to the routing policy, the system receives a signing request containing specific data such as a contract amount of 5 million yuan, 3 signing parties, an urgency score of 8 points, and a maximum score of 10 points. The system will parse the key fields in the request and perform preliminary classification through a preset rule engine. For example, requests with a contract amount greater than 1 million yuan will be marked as high-value contracts, and the number of signatories and urgency score will be recorded. Once the routing strategy is executed, the system checks whether the request explicitly specifies the target platform in the platform-specific routing. If the request specifies platform A, including support for high concurrency and an average response time of 2.5 seconds, the request will be directly routed to platform A and the routing log will be recorded for subsequent tracing. During the intelligent routing phase, if no platform is specified, the system will analyze historical data and real-time performance metrics, calculating scores for each platform using a weighted algorithm. Platform B is pre-set with a stability score of 0.85 and a response speed score of 0.7, while platform C scores 0.75 and 0.8 respectively. The total score is calculated with stability accounting for 60% and acceleration accounting for 40%. The results are as follows: Platform B's score is 0.85 × 0.6 + 0.7 × 0.4 = 0.79; Platform C's score is 0.75 × 0.6 + 0.8 × 0.4 = 0.77; Therefore, platform B was selected as the target platform. In addition, the urgency score was taken into account. If the score was greater than 7, the platform with the faster response time was selected for adjustment. During the degradation routing phase, if platform B selected by the intelligent routing becomes unavailable due to excessive load and the current concurrent requests exceed 1000, the system will automatically trigger the degradation mechanism, query the list of backup platforms, select platform D according to the preset priority, with a load of 600 concurrent requests and a response time of 3.2 seconds, and distribute the requests to platform D through a load balancing algorithm to ensure that the requests are not interrupted. At the same time, the degradation event is recorded to optimize subsequent routing strategies.

[0015] Specifically, in step S101, the intelligent routing platform calculates its overall score: Where S is the platform's overall score, set in a range of 0-1, with higher values ​​indicating stronger platform compatibility; S stab The platform stability score is set in a range of 0-1; Wstab As a stability weight, it is 0.6 in the example, accounting for 60% of the overall score; S speed The platform's response speed is scored, with a range of 0-1. W speed The response speed is weighted at 0.4 in this example, accounting for 40% of the overall score. When no signing platform is specified in the system, the system enters the intelligent routing stage, which requires weighted calculation of the comprehensive score of the two core performance indicators of candidate platforms: stability and response speed, and selects the optimal platform according to the score. If the urgency score of the signing request is greater than 7, the platform with the better response speed will be prioritized based on this result.

[0016] S102. Based on the target signing platform type, call the corresponding adapter from multiple platform adapters registered in a plug-in manner. Furthermore, each adapter encapsulates a protocol converter, a capability mapper, and a state synchronizer.

[0017] Further, in step S102, based on the matching relationship between the target platform and the platform type, the corresponding platform adapter is selected from the pre-established adapter registration library, the basic configuration information of the adapter is obtained, and the accuracy of the adapter selection is determined. By selecting a platform adapter, the protocol conversion module is invoked to adjust the data format for the target platform's communication protocol, resulting in a converted protocol data packet. The system then determines whether the data packet conforms to the target platform's protocol specifications. The data packets output by the protocol conversion module are obtained, and the functional requirements in the data packets are parsed using the capability mapping component. If the parsing result is inconsistent with the functional support of the target platform, the function call logic is adjusted to determine the mapped functional instructions. Based on the mapped function instructions, the status information of the target platform is collected in real time by the status synchronization unit to obtain the current status data of the platform and determine whether the status data meets the instruction execution conditions. The status data collected by the status synchronization unit is used to verify the instruction execution conditions. If the conditions are met, the final execution instruction is generated and the preparation status for instruction issuance is obtained. Based on the prepared state of the instruction, the execution instruction is sent to the target platform. At the same time, the real-time feedback of the instruction execution is monitored through the state synchronization unit to obtain the state update information during the execution process. Obtain status update information, and format the feedback data using the protocol conversion module. If there are any anomalies in the feedback data, record the anomaly log to determine the direction of subsequent processing.

[0018] Specifically, in step S102, during the process of calling the corresponding adapter from multiple pluggable registered platform adapters according to the target signing platform type, the system has pre-determined that the target platform is platform X, which supports specific signing protocols and data formats. The system queries the adapter registration center for the adapter that matches platform X. Adapter X1 is successfully identified, which contains three core components: a protocol converter, a capability mapper, and a state synchronizer. The system initiates a protocol converter to convert the input generic signing data packet, which includes contract number 12345, the SHA256 hash value of the signatory's identity, and a file size of 2.3MB, into the proprietary format required by platform X. During the conversion process, a preset mapping table maps generic fields to platform fields one-to-one. For example, the generic field "sign" is mapped to the platform field. time "Mapped to platform X's "timestamp" sign The data packets are compressed, achieving a compression rate of 30%, reducing the size from 2.3MB to 1.61MB to improve transmission efficiency. The capability mapper is activated and analyzes the feature set supported by platform X. It is found that it supports batch signing but does not support dynamic watermarking. Based on business needs, the system scores the current contract urgency as 6 out of 10 and calculates the feature matching degree, which is 0.82 (calculated as the proportion of supported features 0.6 × 0.9 + the deduction for unsupported features 0.4 × 0.5). It is confirmed that the adapter can meet the requirements, and the unsupported features are recorded in the log. The status synchronizer intervenes to monitor the status changes during the signing process in real time. It queries the status of the platform X every 5 seconds through a heartbeat mechanism. The preset initial status is "pending signing" and is updated to "signing" after 10 seconds. The system synchronizes the status changes with the local database and calculates the status update delay. The current delay is 0.8 seconds, which is lower than the threshold of 1.5 seconds, confirming that the synchronization is normal. To ensure the integrity of the logical chain, if state synchronization fails, the system will automatically trigger a backup synchronization channel and retry every 3 seconds via a backup API interface, up to a maximum of 5 times, to ensure data consistency.

[0019] Specifically, in step S102, the adapter's functional compatibility is calculated: Where M: Functional matching degree, set in the range of 0-1, the higher the value, the stronger the matching degree between the adapter and business requirements; R sup The platform supports a 90% percentage of functions, which is 0.9 in this example, meaning 90% of functions are compatible. W sup To support functional weighting, the example uses 0.6, which accounts for 60% of the match score; D unsupThe deduction value for unsupported functions is 0.5 in this example, which is a quantitative deduction for unsupported functions. W unsup To avoid supporting feature weighting, the example uses 0.4, which accounts for 40% of the match score; After the system calls the target platform adapter, the capability mapper analyzes the difference between the business function requirements and the actual functions supported by the platform. It calculates the function matching degree using this formula. If the matching degree meets the standard, the adapter is confirmed to be usable. At the same time, unsupported functions are recorded in the log to ensure the traceability of business processes.

[0020] S103. Convert the standardized request parameters into the calling format and authentication method of the target platform's native interface, and call its API to initiate the signing task.

[0021] Furthermore, in step S103, the protocol conversion module performs preliminary parsing of the request parameters, identifies the standardized data structure within them, and obtains the parameter content before adjustment. Based on the parameters before adjustment and the native interface specifications of the target platform, perform call format adaptation processing to determine the parameter format that meets the platform requirements. Based on the adapted parameter format, load the relevant configuration of the authentication mode, complete the embedding of authentication data, and obtain the call data with authentication information; By calling data with authentication information, the interface call mechanism of the target platform is triggered to complete the initialization of the signing task and determine whether the task has entered the pending state. If a task enters a pending state, the platform's adaptation components will collect response information after the task is initiated in real time to obtain data updates on the task processing progress. Based on the data updates of the task processing progress, the status monitoring unit is used to track the execution of the signed tasks and determine the final task completion status.

[0022] Specifically, in step S103, during the process of converting the standardized request parameters into the target platform's native interface call format and initiating the signing task, the system parses the input standardized request data. The preset data includes a signing task ID of 98765, a file size of 3.5MB, and a signing deadline of 2023-12-01 15:00:00. The system uses a built-in format conversion engine to map these general parameters to special fields of the target platform Y, for example, mapping "deadline" to "end_time_limit" of platform Y; And according to the requirements of platform Y, the time format was adjusted from "YYYY-MM-DD HH:MM:SS" to "YYYY / MM / DDHH:MM"; Simultaneously, the file data is segmented, with each segment limited to 1MB in size, and divided into 4 segments in total. The last segment is 0.5MB. The system calculates that the estimated time for segmented transmission is 0.2 seconds per segment, with a total estimated time of 0.8 seconds, which is lower than the timeout threshold of 1.2 seconds for platform Y, confirming that the conversion is feasible. The system generates a dynamic token for the authentication method of platform Y, using the HMAC-SHA1 algorithm combined with a timestamp and a key. The key length is 32 bits. The signature value is calculated, with the current timestamp preset to 1700000000. The signature generation takes 0.03 seconds. The signature value is combined with the user identifier (ID U1234) in the request header to obtain complete authentication information. The system verifies that the signature validity period is 300 seconds, and the current remaining validity period is 298 seconds, which meets the platform requirements. The system initiates a signing task through the API of platform Y, using an asynchronous call mode, setting the request timeout to 10 seconds, and the preset response time for the first call to be 2.4 seconds. The system parses the returned response code to be 200, confirming that the task has been successfully submitted, and extracts the task tracking number T56789 and stores it in the local cache. At the same time, the network latency of the API call is calculated to be 0.6 seconds, which is lower than the preset threshold of 1.0 seconds, indicating that the call is stable. To ensure the reliability of the task after submission, the system automatically starts a polling mechanism, checking the task initialization status every 8 seconds. The system is preset to update the status to "received" after 3 queries, which takes 24 seconds. The system compares this status with the local record. If they match, a log record is generated. The log size is 0.02MB and the storage time is 0.01 seconds. If the status is inconsistent, the system will automatically trigger the retry logic, limiting the number of retries to 4, with an interval of 6 seconds between each retrieval, to ensure the accuracy of the task information.

[0023] S104. When initiating a signing task, the standardized signing capabilities are mapped to the signing capabilities actually supported by the target platform. The signing capabilities include the mapping of signing stamp type, identity authentication method, and signing order mode.

[0024] Furthermore, in step S104, the standardized signing capabilities are initially decomposed through the capability mapping unit to identify the core elements related to the capability categories supported by the target platform, and a decomposed capability list is obtained. Based on the decomposed capability list, and for the specific requirements of the signing stamp type, perform the matching operation corresponding to the type to determine the configuration data that matches the stamp type format supported by the platform; By configuring data and combining it with the relevant requirements for identity authentication, implementing a processing flow that is compatible with the implementation method, and obtaining verification parameters that are consistent with the platform's authentication mechanism; Based on the verification parameters and the specific settings of the sequence pattern, adjustment steps for pattern alignment are carried out to obtain sequence rules that match the platform's signing process; By using sequential rules and combining them with the actual capabilities supported by the platform, an integrated conversion process is performed to determine the final capability mapping result. Based on the final capability mapping results, the adjustment unit is used to verify each capability category to obtain a signing capability scheme that is fully aligned with the target platform. By signing the capability agreement, the platform interface call process is triggered to determine whether the capability mapping deployment process has been completed.

[0025] Specifically, in step S104, the standardized signing capability is mapped to the signing capability actually supported by the target platform through the capability mapper. The system automatically matches the signing seal type. The seal type defined in the standardized capability is "company seal", while the target platform Z only supports two types: "electronic seal A" and "electronic seal B". The system analyzes the attributes of the "company seal" using its built-in mapping rule library, sets the size to 50x50 pixels and the color depth to 24 bits, and calculates the similarity between the "electronic seal A" and the types supported by platform Z. The result shows that the matching degree of "electronic seal A" is 92.5%, which is higher than the 78.3% of "electronic seal B". Therefore, "electronic seal A" was automatically selected as the mapping result, taking 0.05 seconds, confirming that the mapping complies with the platform specifications; The system processes the mapping of identity authentication methods. The standardization capability requires dual authentication of "SMS verification code + facial recognition", while platform Z only supports single-factor authentication of "SMS verification code". The system uses a capability degradation algorithm to extract core authentication elements from standardized capabilities. Priority calculation shows that the weight of "SMS verification code" is 0.7, which is higher than that of "face recognition" (0.3). The system automatically selects "SMS verification code" as the target authentication method and records the degradation log. The analysis takes 0.02 seconds, ensuring that the authentication logic is not interrupted. The system maps signing sequence patterns, with the standardization capability defined as "strict sequential signing," meaning it must be completed in the order of 1-2-3, while platform Z supports "partial sequential signing," allowing partial parallel processing. Through pattern compatibility analysis, the system calculated that the implementation cost of "strict sequential signing" on platform Z is 0.1 seconds for each sequential check, and a total of 3 checks are expected to take 0.3 seconds, which is lower than the platform's limit of 0.5 seconds. The system automatically generates sequence constraint rules, breaking down the signing process into three sub-tasks, assigning priorities 1, 2, and 3 respectively to ensure sequential execution. It also associates business rules, so if an abnormal sequence is detected, the system will automatically pause the process and trigger a correction mechanism. The correction is expected to take 0.2 seconds to ensure a smooth process.

[0026] Specifically, in step S104, the signature stamp type matching degree is calculated: Where P represents the chapter type matching degree, expressed as a percentage. The higher the value, the stronger the chapter type attribute matching degree. Attribute matching value i Set the quantization value between 0 and 1 for the matching of individual chapter attributes, including size and color depth; n represents the total number of chapter attributes participating in the matching; The system breaks down the standardized signature stamp types, including the core attributes of corporate seals, such as size and color depth, and performs attribute matching with the stamp types supported by the target platform one by one. The overall matching degree is calculated using this formula, and the platform stamp type with the highest matching degree is taken as the mapping result. In cost calculation using the signing sequence mode: Among them, T total The total implementation time for the signing sequence mode, in seconds, i.e., implementation cost; t single The time taken for a single sequential check is 0.1 seconds per check in this example. N: Total number of sequential checks, which is 3 in the example, corresponding to the signatures of 3 parties; The standardized signing requirement is: strict sequential signing. However, if the target platform only supports partial sequential signing, the system needs to calculate the total time cost of implementing strict sequential signing on the platform. If the total time is lower than the platform's limit threshold, then sequential constraint rules are generated to meet the standardized requirements; if it exceeds the threshold, then the signing mode is adjusted to ensure a smooth process.

[0027] S105. After completing the signing capability mapping and initiating the signing task, a dual-channel mechanism combining active query and passive callback is adopted to synchronize the signing status of the target platform to the unified state machine in real time.

[0028] Furthermore, in step S105, through the status synchronization unit, an active query channel is constructed for the signing status of the target platform, and status acquisition requests are periodically sent to the platform to obtain the latest status data. Based on the configuration of the passive callback channel, when a signing status change occurs on the target platform, a notification message pushed by the platform is received, and the status information after the change is obtained. By integrating data through a dual-channel system, the status data obtained through active querying is compared with the status information received through passive callback to determine consistent status records. For consistent state records, the storage rules of the unified state management module are adopted to write them into the preset state database to obtain synchronized state entries. Based on the synchronized status entries and the update mechanism of the status management module, the platform interaction feedback process is triggered to determine whether the real-time capture of the status has been completed. By capturing status data in real time, corresponding status tracking logs are generated for subsequent business processes on the target platform to determine the final status synchronization result.

[0029] Specifically, in step S105, the signing status of the target platform is synchronized to the unified state machine in real time through a dual-channel mechanism combining active query and passive callback using a state synchronizer. The system periodically sends status acquisition requests to the target platform through the active query mechanism, with the preset query frequency set to once every 5 seconds. The system uses an optimization algorithm based on time windows to analyze the average response time of the last 10 queries, which is 0.08 seconds. If a single query response time is found to exceed 0.15 seconds, the query frequency is automatically adjusted to once every 8 seconds to reduce the platform load. The adjustment process takes 0.03 seconds to ensure query stability. The system incorporates a passive callback mechanism. When the target platform changes its signing status, it will push an update through a preset interface. After receiving the callback data, the system uses a status verification algorithm to compare the current status with the historical records and calculates the consistency score of the status change. If the score is lower than 85%, a secondary verification process is triggered, which takes 0.06 seconds to ensure data accuracy. The system merges the status data obtained from active queries and passive callbacks, and uses a weighted average algorithm to assign a weight of 0.6 to the active query data and a weight of 0.4 to the passive callback data to calculate the final status value. For example, if the current signing progress is 70%, it will be adjusted to 68.2% after merging. The result is then synchronized to the unified state machine, with a synchronization time of 0.04 seconds. To ensure real-time synchronization, the system has a built-in latency monitoring module. If a synchronization delay of more than 0.2 seconds is detected, it will automatically switch to a backup channel. The availability score of the backup channel must reach more than 90%. The switching process takes 0.05 seconds and is closely related to the state update requirements in the business process. This ensures that the state machine can maintain stable operation even in high-concurrency scenarios. The whole process forms a closed-loop logic, from state acquisition to fusion and then to synchronization, to ensure data consistency.

[0030] Specifically, in step S105, the dual-channel state fusion calculation is performed: Among them, S final The final signed status value after integration is expressed as a percentage, including the signing progress. S active The status value is obtained through proactive querying; in this example, it represents a 70% signing progress. W active The weight is actively queried; in this example, it is 0.6, accounting for 60% of the state fusion. S passiveThis is a status value obtained through a passive callback; in this example, it represents a 65% signing progress. W passive The passive callback weight is 0.4 in the example, accounting for 40% of the state fusion. The system obtains the signing status through a dual-channel approach: active query (timed retrieval) and passive callback (platform push). To avoid single-channel data errors, a weighted algorithm is used to fuse the dual-channel status data, and the final fused status value is synchronized to a unified state machine. In determining the weight of identity authentication methods, weights are assigned to each element of the standardized multi-factor authentication method, with a range of 0-1. The element with the highest weight is selected as the authentication method for the target platform. The formula simplifies to: Among them, Auth final The final selected identity authentication method for the target platform is one or more of the standardized authentication elements with the highest weight. max() is a function that retrieves the maximum value, used to filter out the certification element weight value with the highest weight. The weight value of each identity authentication element in the standardized signing capability is in the range of 0-1, where n is the total number of authentication elements required for standardization. The higher the weight value, the stronger the core importance of the authentication element in the business. When the target platform does not support the standardized multi-identity authentication method, the system assigns a core weight to each authentication element in the standardized requirements through a capability degradation algorithm. The system then selects the authentication element with the highest weight using a maximum value function and uses it as the final authentication method for the target platform. This ensures that the authentication logic is not interrupted and that the system matches the actual capabilities of the platform. At the same time, the system records the information about the downgraded authentication method in the log.

[0031] S106. After signing, convert the signed documents and evidence chain returned by the target platform into a unified format and send them back to the core service layer for archiving.

[0032] Furthermore, in step S106, the signed documents and evidence chain are obtained from the target platform through the protocol conversion unit. Preliminary data parsing is performed on the obtained document content and chain information to obtain structured raw data records. The format conversion module is used to standardize the structured raw data records and generate data files that conform to the specifications according to the preset unified format rules. Based on the generated data file that conforms to the specifications, the data file transmission process is initiated using the transmission process control unit. It is determined whether the transmission path conforms to the preset security rules. If it does, the transmission of the data file to the core service is completed. Within the core service layer, the data files transmitted are received through the archiving operation module, the file content is classified and stored, and the storage location of the classified files is determined. Obtain the location information of the data files after classification and storage, and generate corresponding index records for the storage locations using the index building tools within the service layer to obtain a queryable archive index; Based on the queryable archive index, a tracking mechanism within the core service layer is used to mark the completion status of the archive operation. The status is then checked to see if the mark matches the preset status. If they match, the archive process is confirmed to be complete.

[0033] Specifically, in step S106, after signing is completed, the system processes the signed document and evidence chain returned by the target platform through a protocol converter, identifies the file format, and presets that the file returned by the target platform is in PDF format with a size of 2.5MB, and the evidence chain data is in JSON format with a size of 0.3MB. The system uses a format parsing algorithm to analyze the metadata of the PDF file in 0.02 seconds, extracts key fields such as signing time and signer ID, and performs structured parsing of JSON data in 0.01 seconds. If the data field missing ratio exceeds 10% during the parsing process, the data completion logic is automatically triggered. By comparing with the historical records of the target platform, the missing fields are completed, and the completion process takes 0.04 seconds. The system converts the parsed data into a unified format using a standardized XML template. During the conversion process, the file content is divided into blocks, with each block limited to 0.5MB. The conversion efficiency is calculated to be 1.2MB per second, and the overall conversion time is 2.1 seconds. If data anomalies are detected during the conversion process, such as field values ​​exceeding the preset range, the anomaly probability is calculated using a validation algorithm. The preset probability is 8%. If the probability is below the threshold of 15%, processing continues; if it is above the threshold, a log is recorded and a backup module is notified. This process takes 0.03 seconds. The converted data is transmitted back to the core service layer through an encrypted transmission channel at a speed of 5MB per second, taking 0.6 seconds. The system uses a hash verification algorithm to verify the integrity of the transmitted data, calculating a hash value matching degree of 99.8%. If it is lower than 99%, it is retransmitted to ensure that the data is lossless. Once the data reaches the core service layer, the system automatically triggers the archiving process, storing the file in a distributed storage cluster with an allocated storage space of 3MB. The archiving process takes 0.05 seconds, and an archive index is generated simultaneously. The index generation is based on the timestamp and business ID, taking 0.02 seconds. If the storage cluster load exceeds 80%, it automatically switches to a standby node, taking 0.03 seconds. The entire process is linked to subsequent auditing operations to ensure data traceability and form a complete closed loop.

[0034] Specifically, in step S106, the data anomaly detection includes: Field missing percentage: The threshold is 10%; exceeding this threshold will trigger data completion. Data anomaly probability: The threshold is 15%; if it is exceeded, a log will be logged and the backup module will be notified. The verification of transmitted data integrity specifically includes: Hash value matching degree: The threshold is 99%; if it falls below this level, the data is retransmitted to ensure data integrity. In format conversion efficiency calculations, conversion efficiency is: In the embodiments It is used to evaluate conversion performance.

[0035] like Figure 3 As shown, the unified management system for heterogeneous signing platforms with multi-protocol adaptation described in this application includes: Platform type determination module, adapter invocation module, mapping module, status synchronization module, unified archiving module; The output of the platform type determination module is connected to the input of the adapter calling module, and is used to transmit the parsed signing request data to the adapter calling module; The output of the adapter calling module is connected to the input of the mapping module, and is used to transmit the determined target signing platform type and calling instructions to the mapping module; the adapter calling module is used to match a preset routing strategy according to the source identifier, the routing strategy including specified platform routing, intelligent routing and degraded routing, to determine the target signing platform type, and output the target platform type and interface calling instructions to the mapping module; The mapping module and the state synchronization module are bidirectionally connected. The mapping module is used to send signing task information to the state synchronization module, and the state synchronization module is used to feed back the real-time signing status to the mapping module. The mapping module includes an adapter registration library and multiple pluggable registered platform adapters. Each platform adapter encapsulates a protocol converter and a capability mapper. The output end of the mapping module is connected to the input end of the unified archiving module and is used to transmit the signed document and evidence chain data after signing to the unified archiving module. The state synchronization module has a built-in state synchronizer, which adopts a dual-channel mechanism combining active query and passive callback to collect the signing status of the target platform and synchronize it to the unified state machine, while feeding back the signing status to the mapping module in real time. The platform type determination module is used to receive external signing requests through the unified signing interface, parse the request data to obtain basic request information and source identifier, and output the parsed standardized request data to the adapter calling module; The unified archiving module receives the signed documents and evidence chains output by the mapping module, converts them into a unified format through a protocol converter, and then sends them back to the core service layer to complete the archiving storage and archiving index generation.

[0036] In one embodiment, a unified management system for heterogeneous signing platforms with multi-protocol adaptability is disclosed. The hardware is mounted on an enterprise-grade server, and the software is deployed in a microservice architecture, comprising five core modules: Platform type determination module 1 is used to receive signing requests through the unified signing interface and determine the target signing platform type according to the routing strategy. Specifically, the target platform is selected by specified, intelligent or degraded routing. The target platform includes, but is not limited to, E-Sign and self-developed signing platforms. Adapter calling module 2 is used to call the corresponding adapter from multiple platform adapters registered in a pluggable manner based on the target signing platform type, without modifying the core code; Mapping module 3 is used to map standardized signing capabilities to the actual signing capabilities supported by the target platform when initiating a signing task. The signing capabilities include signing stamp type mapping, identity authentication method mapping, and signing order mode mapping. The state synchronization module 4 is used to synchronize the signing status of the target platform to the unified state machine in real time after completing the signing capability mapping and initiating the signing task, using a dual-channel mechanism that combines active query and passive callback. The unified archiving module 5 is used to convert the signed documents and evidence chains returned by the target platform into a unified format after signing is completed, and then send them back to the core service layer to complete archiving.

[0037] In a system operation example, the enterprise initiates a tripartite contract signing request without specifying a platform: The platform type determination module selects the Fadada platform with the lowest load using intelligent routing; the adapter call module loads the Fadada adapter, and the protocol converter converts the request parameters and authentication information; the capability mapper maps "company seal", "face authentication", and "sequential signing" to capabilities supported by Fadada; the status synchronization module actively queries and receives callbacks every 5 seconds, synchronizing the status from "pending signing" to "signing in progress" to "completed" in real time; after signing, the unified archiving module converts the PDF contract and evidence chain into a unified format and archives them to the enterprise core service layer.

[0038] In one embodiment, an electronic device is provided, comprising: Processor: An enterprise-grade CPU used to execute program instructions; Memory: Non-volatile storage, used to store computer programs; Communication interface: Used to interface with the APIs of various signing platforms; Bus: Connects the processor, memory, and communication interface; It should be noted that when the computer program in the memory is executed by the processor, it implements all the steps of the aforementioned unified management method for heterogeneous signing platforms with multi-protocol adaptation.

[0039] In one embodiment, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, implements the method for unified management of heterogeneous signing platforms with multi-protocol adaptation as described in the method embodiment. Media type: Non-temporary readable storage media such as USB flash drives, hard drives, server storage, ROM, and optical discs can be used.

[0040] The above description is merely a preferred embodiment of one or more embodiments of this specification and is not intended to limit the scope of one or more embodiments of this specification. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of one or more embodiments of this specification should be included within the scope of protection of one or more embodiments of this specification.

Claims

1. A unified management method for heterogeneous signing platforms with multi-protocol adaptation, characterized in that, include: S101. Receive signing requests through the unified signing interface and determine the target signing platform type according to the routing policy; S102. Based on the target signing platform type, call the corresponding adapter from the multiple platform adapters registered in plug-in mode; S103. Convert the standardized request parameters into the calling format and authentication method of the target platform's native interface, and call its API to initiate a signing task; S104. When initiating a signing task, the standardized signing capabilities are mapped to the signing capabilities actually supported by the target platform. The signing capabilities include the mapping of signing stamp type, identity authentication method, and signing order mode. S105. After completing the signing capability mapping and initiating the signing task, a dual-channel mechanism combining active query and passive callback is adopted to synchronize the signing status of the target platform to the unified state machine in real time. S106. After signing, convert the signed documents and evidence chain returned by the target platform into a unified format and send them back to the core service layer for archiving.

2. The unified management method for heterogeneous signing platforms with multi-protocol adaptation according to claim 1, characterized in that, S101 includes: The signing request data is obtained through a unified interface, and the source identifier is obtained by parsing the signing request data. Match the pre-defined routing policy database based on the parsed source identifier; If the specified routing conditions are met, the target platform type is determined directly; if not, intelligent routing logic is used to determine the target platform type based on platform load. If the platform load exceeds the preset threshold, switch to the backup platform type and trigger a degraded route.

3. The unified management method for heterogeneous signing platforms with multi-protocol adaptation according to claim 1, characterized in that, Following S102, the following is also included: Adjust the data format of the target platform's communication protocol to obtain the converted protocol data packets; Parse the functional requirements in the protocol data packet. If they are inconsistent with the functional support of the target platform, adjust the calling logic and determine the mapped functional instructions. Based on the mapped function instructions, collect the status data of the target platform and verify the instruction execution conditions; If the conditions are met, the execution instructions for the function instructions are generated, and the execution instructions are obtained and issued.

4. The unified management method for heterogeneous signing platforms with multi-protocol adaptation according to claim 1, characterized in that, S105 includes: Establish an active query channel to periodically send status retrieval requests to the target platform to obtain the latest status data; Simultaneously, it receives status change notification messages pushed by the platform through a passive callback channel; The latest status data obtained through active query is compared with the changed status information from the passive callback channel to identify consistent status records. The status records are written into a preset status library to complete the real-time capture of the status.

5. The unified management method for heterogeneous signing platforms with multi-protocol adaptation according to claim 1, characterized in that, S106 includes: Obtain signed documents and evidence chains from the target platform, perform preliminary data analysis, and obtain structured raw data records; The original data records are standardized, and data files conforming to the specifications are generated according to unified format rules; The transmission process is initiated, and it is determined whether the transmission path complies with security rules. If it does, the data file is transferred to the core service layer. The core service layer classifies and stores the received data file to determine the storage location and generate a queryable archive index.

6. A system for unified management of heterogeneous signing platforms with multi-protocol adaptation, characterized in that, include: The platform type determination module is used to receive signing requests through the unified signing interface and determine the target signing platform type based on the routing strategy. The adapter invocation module is used to invoke the corresponding adapter from multiple pluggable platform adapters based on the target signing platform type; The mapping module is used to map standardized signing capabilities to the actual signing capabilities supported by the target platform when initiating a signing task. The signing capabilities include signing stamp type mapping, identity authentication method mapping, and signing order mode mapping. The state synchronization module is used to synchronize the signing status of the target platform to the unified state machine in real time after completing the signing capability mapping and initiating the signing task, using a dual-channel mechanism that combines active query and passive callback. The unified archiving module is used to convert the signed documents and evidence chains returned by the target platform into a unified format after signing, and then send them back to the core service layer to complete archiving.

7. The unified management system for heterogeneous signing platforms with multi-protocol adaptation according to claim 6, characterized in that, The mapping module includes an adapter registration library and multiple pluggable platform adapters; the platform adapters encapsulate protocol converters and capability mappers. The protocol converter is used to convert standardized request parameters into the calling format and authentication method of the target platform's native interface, and to call its API to initiate a signing task. It is also used to convert the signed documents and evidence chains returned by the target platform into a unified format.

8. The unified management system for heterogeneous signing platforms with multi-protocol adaptation according to claim 6, characterized in that, The state synchronization module is also used to build an active query channel, periodically send a state acquisition request to the target platform to obtain the latest state data; at the same time, it receives state change notification messages pushed by the platform through a passive callback channel. The latest status data obtained through active query is compared with the changed status information from the passive callback channel to identify consistent status records; the status records are then written into a preset status database to complete real-time status capture.

9. An electronic device, characterized in that, The system includes a storage device and a processor, wherein the storage device stores a computer program, and when the computer program is executed by the processor, the processor causes the processor to perform the steps of the multi-protocol adapted heterogeneous signing platform unified management method as described in any one of claims 1 to 5.

10. A computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the steps of the unified management method for heterogeneous signing platforms with multi-protocol adaptation as described in any one of claims 1 to 5.

Images