Multi-party cooperative consumption endowment insurance service method and system

Abstract

This invention relates to the field of insurance service data processing and distributed task scheduling technology, and particularly to a multi-party collaborative consumer pension security service method and system. The method includes: acquiring multi-protocol consumer order data, generating order request packets through protocol identification, authentication, and verification; identifying merchant types and consumption scenarios, and outputting routing results; retrieving merchant rebate ratios and revenue sharing templates to complete revenue sharing calculations, and creating process instances with consumption, revenue sharing, custody, and insurance status nodes; calling payment institutions, bank custody, and insurance core interfaces based on the process instance status; performing compensation processing and generating compensation results using the Saga pattern for interface execution failures, timeouts, or expiration anomalies; generating key transaction hashes and writing them to the blockchain to form a notarized record; and building a business query index by monitoring database logs and synchronizing them to a search engine. This invention effectively enhances the auditability of the transaction chain and improves operational analysis efficiency.

Description

Technical Field

[0001] This invention relates to the field of insurance service data processing and distributed task scheduling technology, and in particular to a multi-party collaborative consumer pension security service method and system. Background Technology

[0002] In the field of insurance service data processing and distributed task scheduling technology, existing solutions typically receive consumer order data from sales terminals, e-commerce platforms, or mobile applications. They then complete consumption, revenue sharing, custody, and insurance-related processing through merchant authentication, order routing, revenue sharing calculation, payment institution interfaces, bank custody interfaces, and core insurance interfaces. However, these solutions suffer from limitations such as inconsistent data formats across multiple protocols, inconsistent interface return statuses, and unclear connections between status nodes. Existing methods often rely on order status fields, interface callback results, or manual verification records to advance subsequent processing, leading to difficulties in consistently determining revenue sharing results, bank custody status, policy query results, and premium increase results.

[0003] In scenarios where payment institution interfaces, bank custody interfaces, and insurance core interfaces are processed in a chain, pain points can easily arise, such as the payment institution interface completing real-time settlement while the bank custody interface freezes funds or the transfer fails; the bank custody interface returning the funds to a frozen state while the insurance core interface fails to query the policy; and the bank custody interface returning the funds to a transfer state while the insurance core interface times out on premium addition results. These issues make it difficult to meet the requirement for stable connection between consumption, settlement, custody, and insurance status nodes. Because existing solutions typically lack a unified record of process instance status, failures, timeouts, or processing overdues in the interface execution status are difficult to distinguish and process according to completed status nodes, easily leading to unclear selection criteria between refunds, unfreezing, reverse transfers, premium addition result queries, or marking as pending.

[0004] For the joint processing of interface execution status, process instance status, and compensation process results, existing technologies generally focus on order acceptance, work order collaboration, payment result display, or query record updates. They do not adequately record the dependencies between the accounting status nodes, custody status nodes, and insurance status nodes. This makes it difficult to form a consistent process in multi-party collaborative consumer pension security service scenarios, including order request data packets, accounting calculation results, process instance status, interface execution status, compensation process results, evidence storage records, and query indexes. Consequently, it is difficult to record and trace abnormal states in the accounting, custody, and insurance processing links according to the same process instance. Summary of the Invention

[0005] To address the aforementioned technical problems, this invention provides a multi-party collaborative method for providing consumer-based elderly care security services, comprising:

[0006] S100: Obtain multi-protocol consumer order data generated by POS machines, e-commerce platforms, or mobile apps, and sequentially perform HTTP / HTTPS, MQ, and RPC protocol identification, merchant authentication, field mapping, and idempotency verification to generate an order request data packet;

[0007] S200: Based on the order request data packet, complete the identification of merchant type, online and offline scenarios and user policy information, and output the order routing result;

[0008] S300. Based on the order routing results, retrieve the merchant rebate ratio and revenue sharing template, complete the revenue sharing amount calculation, and obtain the revenue sharing calculation result.

[0009] S400. Based on the revenue sharing calculation results, create a process instance and configure the corresponding status nodes for consumption, revenue sharing, custody, and insurance, and determine the status of the process instance.

[0010] S500. Based on the status of the process instance, call the payment institution interface for real-time settlement, the bank custody interface to complete the freezing or transfer of funds, and the insurance core interface to realize policy inquiry and premium addition, and provide feedback on the interface execution status.

[0011] S600. For the execution status of the interface, identify failure, timeout, and expiration exceptions, and perform compensation processing in Saga mode to generate compensation process results.

[0012] S700. Based on the results of the compensation process, generate a key transaction hash and write it into the blockchain notarization node to form a notarization record.

[0013] S800: Based on the stored evidence records, use Canal to monitor MySQL Binlog logs and synchronize them to Elasticsearch to build a business query index.

[0014] Furthermore, the processes for HTTP / HTTPS, MQ, RPC protocol identification, merchant authentication, field mapping, and idempotency validation include:

[0015] The protocol identification process includes: the multi-protocol gateway reads the source identifier, request header information, message topic and service call information, identifies the HTTP, HTTPS, MQ or RPC protocol type, and writes the protocol type into the processing status of the multi-protocol consumption order data;

[0016] The merchant authentication process includes: the multi-protocol gateway performs merchant identifier matching, source identifier matching, and payment channel matching based on the merchant identifier, source identifier matching, and payment channel matching, and writes the merchant authentication result into the processing status after all matching passes.

[0017] The field mapping process includes: the multi-protocol gateway organizes the offline order fields from the POS machine, the online order fields from the e-commerce platform, and the user order fields from the mobile APP into unified fields such as merchant identifier, user identifier, order amount, order time, and payment channel to form intermediate data;

[0018] The idempotency verification process includes: the multi-protocol gateway performs duplicate identification on the intermediate data based on the same merchant identifier, the same user identifier, the same order amount, and the same order time; when no duplicate records are found, it generates an idempotency verification result in a passed state; and encapsulates the merchant identifier, user identifier, order amount, order time, payment channel, protocol type, merchant authentication result, and idempotency verification result into an order request data packet.

[0019] Furthermore, the process of identifying and processing merchant types, online and offline scenarios, and user policy information includes:

[0020] The merchant type identification process includes: the order routing engine reads the merchant authentication result and idempotency verification result in the order request data packet, and when both are in a passed state, reads the merchant identifier and payment channel, matches them with the merchant access information stored in the business logic layer, and identifies the merchant type as online merchant, offline merchant, or merchant with both online and offline access records.

[0021] The online and offline scenario identification and processing includes: the order routing engine identifies the offline consumption scenario based on the protocol type, payment channel and the source of the order request data packet. If the data packet originates from a POS machine and the payment channel corresponds to an offline payment channel, it is identified as an offline consumption scenario. If the data packet originates from an e-commerce platform or mobile APP and the payment channel corresponds to an online payment channel, it is identified as an online consumption scenario.

[0022] The user policy information identification and processing includes: the order routing engine reads user policy information from Redis and L1 local cache first, based on the user identifier; if the read is not found, it initiates a policy query to obtain user policy information containing user identifier, policy status and premium addition association information.

[0023] The order routing engine combines the merchant type, consumption scenario, user policy information, merchant identifier, user identifier, order amount, order time, and payment channel to form the order routing result.

[0024] Furthermore, the process of retrieving merchant rebate ratios and revenue sharing templates and completing revenue sharing amount calculation includes:

[0025] The process of retrieving merchant rebate ratios and revenue sharing templates includes: the rule configuration center reading the merchant identifier and merchant type from the order routing results, searching for the corresponding merchant rebate ratio in the hot merchant configuration; then reading the consumption scenario and payment channel, and searching for the revenue sharing template corresponding to the consumption scenario and payment channel; the revenue sharing template includes the real-time revenue sharing data generation rules of the payment institution interface, the fund freezing or transfer data generation rules of the bank custody interface, and the premium increase data generation rules of the insurance core interface.

[0026] The revenue sharing calculation process includes: the rule configuration center obtains the consumption incentive amount based on the order amount and the merchant rebate ratio, and then organizes the consumption incentive amount into real-time revenue sharing data of the payment institution interface, fund freezing or transfer data of the bank custody interface, and premium addition data of the insurance core interface according to the revenue sharing template; the revenue sharing calculation result includes merchant identifier, user identifier, order amount, order time, payment channel, merchant rebate ratio, revenue sharing template, consumption incentive amount, real-time revenue sharing data, fund freezing or transfer data, and premium addition data.

[0027] Furthermore, the process of creating a process instance and configuring the corresponding status node processing for consumption, revenue sharing, custody, and insurance includes:

[0028] The creation process instance includes: the workflow engine reads the merchant identifier, user identifier, order amount, order time, and payment channel from the revenue sharing calculation result as basic fields, and then reads the consumption incentive amount, real-time revenue sharing data, fund freezing or transfer data, and premium addition data as processing data. When all of these exist, a process instance is created, and a corresponding relationship is established with the order request data packet, order routing result, and revenue sharing calculation result.

[0029] The configuration status nodes include: the workflow engine sets consumption status nodes, revenue sharing status nodes, custody status nodes, and insurance status nodes in the process instance; the consumption status node records merchant identifier, user identifier, order amount, order time, and payment channel; the revenue sharing status node records consumption incentive amount and real-time revenue sharing data; the custody status node records fund freezing or transfer data; and the insurance status node records premium increase data.

[0030] The status nodes are written into the node sequence record in the order of consumption status node, accounting status node, custody status node, and insurance status node, and the status transition result of the previous status node is used as the processing data for the subsequent status node; the workflow engine generates a process instance status that includes the process instance, each status node, node sequence record, and status transition result.

[0031] Furthermore, the process of calling the payment institution's interface for real-time settlement, the bank's custody interface for freezing or transferring funds, and the insurance core interface for policy inquiry and premium increase processing includes:

[0032] The process of calling the payment institution interface includes: the workflow engine reading the splitting status node in the process instance status, extracting real-time splitting data and calling the payment institution interface to receive the splitting result, which includes the status of success, failure, timeout or processing.

[0033] The process of calling the bank custody interface includes: when the settlement result is successful, the workflow engine reads the fund freezing or transfer data in the custody status node and calls the bank custody interface to receive the bank custody status including the status of successful fund freezing, successful fund transfer, failure, timeout or processing.

[0034] The process of calling the insurance core interface includes: when the bank custody status is successful fund freezing or successful fund transfer, the workflow engine reads the premium addition data and user policy information in the insurance status node, calls the insurance core interface to perform policy query and premium addition, and receives premium addition results including success, failure, timeout or processing status.

[0035] The workflow engine combines the revenue sharing results, bank custody status, and premium increase results into the interface execution status.

[0036] Furthermore, the process of identifying failures, timeouts, and expirations and performing compensation processing using the Saga pattern includes:

[0037] The anomaly identification includes: the workflow engine reads the revenue sharing result in the interface execution status; if it is a failure, timeout, or processing overdue, the revenue sharing status node is recorded as pending; if the revenue sharing result is successful, it continues to read the bank custody status; if the bank custody status is a failure, timeout, or processing overdue, Saga compensation is initiated; if the bank custody status is a successful fund freeze, the policy query result is read; if the policy query result is a failure, timeout, or processing overdue, the unfreezing process is executed; if the bank custody status is a successful fund transfer, the premium addition result is read; if the premium addition result is a failure, timeout, or processing overdue, a reverse transfer or premium addition result query is executed.

[0038] The Saga mode compensation process includes: when the settlement result is successful but the bank custody status is failed, timed out, or overdue during processing, the workflow engine processes the refund or marks it as pending based on the settlement result recorded in the settlement status node; when the funds are successfully frozen but the policy query result is abnormal, the workflow engine performs the unfreezing process; when the funds are successfully transferred but the premium increase result is abnormal, the workflow engine performs the reverse transfer, premium increase result query, or marks it as pending.

[0039] The compensation process results include process instance, account splitting results, bank custody status, policy inquiry results, premium increase results, refund records, unfreezing records, reverse transfer records, premium increase result inquiry records, pending records, and compensation processing time.

[0040] Furthermore, the process of generating key transaction hashes and writing them to the blockchain's evidence storage nodes includes:

[0041] The generation of the key transaction hash includes: the workflow engine reads the process instance in the compensation process result, retrieves the corresponding order request data packet, revenue sharing calculation result and process instance status, extracts the merchant identifier, user identifier, order amount, order time, revenue sharing result, bank custody status, premium addition result, compensation process result and process instance status as necessary fields, arranges them in the order of order request data packet, revenue sharing result, bank custody status, premium addition result, compensation process result and process instance status, and performs hash processing on the arranged fields to obtain the key transaction hash;

[0042] The process of writing to the blockchain evidence storage node includes: the workflow engine encapsulating key transaction hashes, process instances, compensation process results, and process instance status into evidence storage writing data and sending it to the blockchain evidence storage node; after receiving the data, the blockchain evidence storage node performs key transaction hash writing, process instance writing, and compensation process result writing, and returns the writing status; the workflow engine generates evidence storage records based on the writing status.

[0043] Furthermore, the process by which Canal monitors MySQL Binlog logs and synchronizes them to Elasticsearch includes:

[0044] The Canal monitoring of the MySQL Binlog includes: the data layer reading process instances and key transaction hashes from the evidence storage records to determine the consumer order data, billing results, bank custody status, premium addition results, and compensation process results that need to be monitored; Canal monitoring data changes corresponding to the process instances in the MySQL Binlog, matching the changed fields with the process instances, and generating heterogeneous data synchronization results containing the process instance, key transaction hashes, consumer order data, billing results, bank custody status, premium addition results, compensation process results, and change time;

[0045] The synchronization to Elasticsearch includes: after receiving the heterogeneous data synchronization results, Elasticsearch organizes the fields, reads the process instance, key transaction hash, merchant identifier, user identifier, order amount, order time, payment channel, revenue sharing result, bank custody status, premium addition result, and compensation process result, and organizes them into query fields in the same query index; it establishes the main query field based on the process instance, the merchant-side query field based on the merchant identifier, the user-side query field based on the user identifier, and the evidence record query field based on the key transaction hash, and generates a business query index.

[0046] Furthermore, a multi-party collaborative consumer-based elderly care security service system includes: an order access module, an order routing module, a rule configuration module, a workflow module, an external interface module, a compensation processing module, an evidence storage processing module, and a query synchronization module; the modules are connected in sequence to implement any of the methods described above.

[0047] The key innovations of this invention include:

[0048] (1) Create a process instance based on the revenue sharing calculation result, and set consumption, revenue sharing, custody and insurance status nodes in the process instance, so that the order request data packet, the revenue sharing calculation result, the bank custody status and the premium addition result enter the corresponding status nodes respectively.

[0049] (2) Based on the execution status of the interface, determine failure, timeout or processing overdue, and compensate through Saga mode. Under the accounting, custody and insurance status nodes, generate refund, unfreezing, reverse transfer, premium increase result query or mark as pending compensation process result.

[0050] (3) Generate key transaction hashes based on the results of the compensation process and write them into the blockchain storage node. Then, based on the storage records, perform Canal monitoring, MySQL Binlog and Elasticsearch synchronization processing to form a query index corresponding to the process instance.

[0051] The following are its main beneficial effects:

[0052] (1) To address the problem of unclear connection between consumption, accounting, custody and insurance in the existing scheme, the consumption, accounting, custody and insurance status nodes are recorded through the process instance status record, so that the accounting calculation result has a unified status carrier object before entering the subsequent payment institution interface, bank custody interface and insurance core interface for processing.

[0053] (2) To address the issue of inconsistent return statuses from the payment institution interface, bank custody interface, and insurance core interface, compensation processing is performed using the interface execution status and Saga mode to ensure that failures, timeouts, or processing overdues can proceed to the corresponding compensation process results according to the completed status nodes.

[0054] (3) To address the problem that it is difficult to continuously determine the results of the split account, the bank custody status, the policy query results and the premium increase results, the process instance status and the interface execution status are linked together to ensure that the refund, unfreezing, reverse transfer, premium increase result query or marking as pending have corresponding status node basis.

[0055] (4) To address the issue of scattered transaction records after compensation processing, a key transaction hash is generated through the compensation process result, and the key transaction hash is written into the blockchain storage node, so that the order request data packet, the accounting result, the bank custody status, the premium addition result and the compensation process result enter the same storage record.

[0056] (5) To address the problem of disconnect between query record updates and status node processing in the existing solution, Canal monitors MySQL Binlog and Elasticsearch for synchronous processing, so that the evidence record, the query index, the process instance status and the compensation process result form a continuous data processing link. Attached Figure Description

[0057] Figure 1 A flowchart illustrating a multi-party collaborative consumer-based elderly care security service method provided in this application embodiment;

[0058] Figure 2 This is a structural block diagram of a multi-party collaborative consumer-based elderly care security service system provided in an embodiment of this application. Detailed Implementation

[0059] Example 1: Refer to Figure 1 This is a flowchart illustrating a multi-party collaborative consumer-based elderly care security service method provided by an embodiment of the present invention. The process may include at least steps S100-S800:

[0060] S100: Obtain multi-protocol consumer order data generated by POS machines, e-commerce platforms, or mobile apps, and sequentially perform HTTP / HTTPS, MQ, and RPC protocol identification, merchant authentication, field mapping, and idempotency verification to generate an order request data packet;

[0061] S200: Based on the order request data packet, complete the identification of merchant type, online and offline scenarios and user policy information, and output the order routing result;

[0062] S300. Based on the order routing results, retrieve the merchant rebate ratio and revenue sharing template, complete the revenue sharing amount calculation, and obtain the revenue sharing calculation result.

[0063] S400. Based on the revenue sharing calculation results, create a process instance and configure the corresponding status nodes for consumption, revenue sharing, custody, and insurance, and determine the status of the process instance.

[0064] S500. Based on the status of the process instance, call the payment institution interface for real-time settlement, the bank custody interface to complete the freezing or transfer of funds, and the insurance core interface to realize policy inquiry and premium addition, and provide feedback on the interface execution status.

[0065] S600. For the execution status of the interface, identify failure, timeout, and expiration exceptions, and perform compensation processing in Saga mode to generate compensation process results.

[0066] S700. Based on the results of the compensation process, generate a key transaction hash and write it into the blockchain notarization node to form a notarization record.

[0067] S800: Based on the stored evidence records, use Canal to monitor MySQL Binlog logs and synchronize them to Elasticsearch to build a business query index.

[0068] S100: Obtain multi-protocol consumer order data from POS machines, e-commerce platforms, or mobile apps; perform HTTP / HTTPS, MQ, or RPC protocol identification, merchant authentication, field mapping, and idempotency verification to obtain the order request data packet.

[0069] The data received in this step comes from point-of-sale (POS) terminals, e-commerce platforms, or mobile applications (APPs). The POS terminal is the order initiation terminal in offline consumption scenarios. The e-commerce platform is the order initiation system in online consumption scenarios. The mobile APP is the application terminal where users initiate consumption orders via mobile terminals. The multi-protocol consumption order data is data generated from the above sources and submitted to the access layer. The data content includes source identifier, request header information, message subject, service call information, merchant identifier, user identifier, order amount, order time, and payment channel. The multi-protocol gateway in the access layer initiates this step upon receiving the multi-protocol consumption order data. The merchant identifier, user identifier, order amount, order time, and payment channel are necessary fields for generating the order request data packet, while the source identifier, request header information, message subject, and service call information are determination fields for protocol identification processing.

[0070] Specifically, the multi-protocol gateway first reads the source identifier, the request header information, the message subject, and the service call information, and then performs protocol identification processing based on these information, including Hypertext Transfer Protocol (HTTP), Hypertext Transfer Protocol Secure (HTTPS), Message Queue (MQ), or Remote Procedure Call (RPC). For multi-protocol consumer order data accessed via HTTP or HTTPS, the multi-protocol gateway reads the request header information and the source identifier, and extracts the merchant identifier, user identifier, order amount, order time, and payment channel from the request body. For multi-protocol consumer order data accessed via MQ, the multi-protocol gateway reads the message subject and message content, and extracts the merchant identifier, user identifier, order amount, order time, and payment channel from the message content. For multi-protocol consumer order data accessed via RPC, the multi-protocol gateway reads the service call information, and extracts the merchant identifier, user identifier, order amount, order time, and payment channel from the service call parameters. After the protocol identification processing is completed, the multi-protocol gateway writes the identified protocol type into the processing status of the multi-protocol consumer order data.

[0071] Furthermore, the multi-protocol gateway performs merchant authentication based on the merchant identifier, the source identifier, and the payment channel. The merchant authentication process includes merchant identifier matching, source identifier matching, and payment channel matching. Merchant identifier matching verifies whether the merchant corresponding to the merchant identifier exists in the merchant access information stored at the access layer. Source identifier matching verifies whether the multi-protocol consumer order data originates from an access source registered in a POS machine, e-commerce platform, or mobile app. Payment channel matching verifies whether the payment channel matches the access record corresponding to the merchant identifier. When all the aforementioned matches pass, the multi-protocol gateway writes the merchant authentication result to the processing status and sends the multi-protocol consumer order data to the field mapping processing; when any of the aforementioned matches fail, the multi-protocol gateway terminates the field mapping processing and marks the multi-protocol consumer order data as pending processing.

[0072] Furthermore, the field mapping process is performed by the multi-protocol gateway. This process consolidates fields from different sources and protocols into a unified field. Offline order fields from POS machines, online order fields from e-commerce platforms, and user order fields from mobile apps are all consolidated into merchant identifier, user identifier, order amount, order time, and payment channel. The merchant identifier is used for merchant type identification in subsequent S200. The user identifier is used for user policy information identification in subsequent S200. The order amount is used for revenue sharing calculation in subsequent S300. The order time is used for idempotency verification and subsequent status transition recording. The payment channel is used for order routing result generation in subsequent S200. After the field mapping process is completed, the multi-protocol gateway generates unified intermediate data and sends this intermediate data to the idempotency verification process.

[0073] Furthermore, the idempotency verification process is based on the merchant identifier, the user identifier, the order amount, and the order time. The multi-protocol gateway performs duplicate identification on multi-protocol consumer order data corresponding to the same merchant identifier, user identifier, order amount, and order time. When the multi-protocol gateway does not find duplicate records, it generates an idempotency verification result in a passed state. When the multi-protocol gateway finds duplicate records, it generates an idempotency verification result in a duplicate state and writes the duplicate state into the processing state. For idempotency verification results in a passed state, the multi-protocol gateway encapsulates the merchant identifier, user identifier, order amount, order time, payment channel, protocol type, merchant authentication result, and idempotency verification result into an order request data packet. For idempotency verification results in a duplicate state, the multi-protocol gateway does not generate a new order request data packet and marks the corresponding multi-protocol consumer order data as pending processing.

[0074] Understandably, in a real-world scenario, an offline merchant submits a purchase order through a POS machine. The multi-protocol gateway reads the source identifier and request header information corresponding to the POS machine to identify whether the multi-protocol purchase order data belongs to HTTP or HTTPS access. Subsequently, the multi-protocol gateway extracts the merchant identifier, user identifier, order amount, order time, and payment channel, and matches the merchant identifier with the registered merchant access information. After a successful match, the multi-protocol gateway organizes the original fields from the POS machine into unified fields, and then performs idempotency verification using the merchant identifier, user identifier, order amount, and order time. If no duplicate records are found, an order request data packet is generated. The merchant identifier, user identifier, order amount, order time, and payment channel in the order request data packet are entered into S200 as input for the order routing engine to identify and process merchant type, online / offline, and user policy information.

[0075] In summary, the technical effects of this step are as follows: This step organizes multi-protocol consumer order data generated by POS machines, e-commerce platforms, or mobile apps into order request data packets, forming a unified input for subsequent state transitions. This step centralizes protocol identification, merchant authentication, field mapping, and idempotency verification at the access layer, reducing redundant processing of access differences by the business logic layer. The merchant identifier, user identifier, order amount, order time, payment channel, and idempotency verification results generated in this step are input into S200, supporting the generation of order routing results.

[0076] S200. Based on the order request data packet, perform merchant type, online / offline and user policy information identification processing to obtain order routing results;

[0077] This step follows the order request data packet generated by S100 and is processed by the order routing engine in the business logic layer. The order request data packet is the input data for this step, containing merchant identifier, user identifier, order amount, order time, payment channel, protocol type, merchant authentication result, and idempotency verification result. The order routing engine is a processing module located in the business logic layer, used to read the fields in the order request data packet and redirect consumer orders from different sources to the corresponding revenue sharing strategy. The merchant type is the online merchant, offline merchant, or merchant category with both online and offline access records corresponding to the merchant identifier. "Online / offline" refers to the consumption scenario identification result; online corresponds to consumer orders generated by e-commerce platforms or mobile apps, and offline corresponds to consumer orders generated by POS machines. The user policy information is policy query data obtained based on the user identifier, including the user identifier, policy status, and premium increase association information.

[0078] Specifically, the order routing engine first reads the merchant authentication result and idempotency verification result from the order request data packet. When both the merchant authentication result and the idempotency verification result are passed, the order routing engine proceeds to merchant type identification processing. When either the merchant authentication result or the idempotency verification result is pending, the order routing engine does not proceed to subsequent merchant type identification processing and records the order request data packet as pending. During merchant type identification processing, the order routing engine reads the merchant identifier and the payment channel and matches them with the merchant access information stored in the business logic layer. The merchant access information includes the merchant identifier, access source, payment channel, and revenue sharing strategy association record. The order routing engine identifies the merchant type based on the access source corresponding to the merchant identifier and writes the identified merchant type into the processing record.

[0079] Furthermore, the order routing engine performs online / offline identification processing based on the protocol type, payment channel, and the source of the order request data packet. The protocol type originates from the HTTP / HTTPS, MQ, or RPC protocol identification processing in S100. If the order request data packet originates from a POS machine and the payment channel corresponds to an offline payment channel, it is identified as an offline consumption scenario. If the order request data packet originates from an e-commerce platform or mobile APP and the payment channel corresponds to an online payment channel, it is identified as an online consumption scenario. If the same merchant identifier has access records from POS machines, e-commerce platforms, or mobile APPs simultaneously, the order routing engine reads the source identifier and the payment channel and matches the source identifier with the payment channel. After matching, the order routing engine generates a consumption scenario and writes the consumption scenario into the processing record. The consumption scenario is used to distinguish the merchant rebate ratio and revenue sharing template read in S300 subsequently.

[0080] Furthermore, the order routing engine performs user policy information identification processing based on the user identifier. Before performing the user policy information identification processing, the business logic layer reads the hot merchant configuration and user policy information. The hot merchant configuration includes merchant access information, merchant rebate ratio association records, and revenue sharing strategy association records corresponding to high-frequency consumption merchants. The user policy information is preferentially read from Redis and L1 local cache. Redis is a distributed cache, and the L1 local cache is a local cache in the business logic layer service instance. When a read hit occurs, the order routing engine directly obtains the user policy information. When a read miss occurs, the order routing engine initiates a policy query and writes the retrieved user policy information into the processing record. The user policy information includes the user identifier, policy status, and premium addition association information. If the user policy information does not exist or is recorded as pending processing, the order routing engine marks the order request data packet as pending processing and records the reason for pending processing.

[0081] Understandably, in actual operation scenarios, after an offline merchant generates an order request data packet through a POS machine, the order routing engine reads the merchant identifier, user identifier, order amount, and payment channel from the order request data packet. The order routing engine first identifies the merchant type through merchant access information, and then identifies it as an offline consumption scenario through the source identifier and payment channel. Subsequently, the order routing engine reads the user's policy information based on the user identifier. If the user's policy information exists in Redis or the L1 local cache, the order routing engine writes the cached user's policy information into the processing record. If it does not exist in the cache, the order routing engine initiates a policy query and writes the returned user's policy information into the processing record. For order request data packets submitted by e-commerce platforms or mobile apps, the order routing engine uses the same field reading method and identifies it as an online consumption scenario based on the source identifier and payment channel.

[0082] Furthermore, the order routing engine combines the merchant type, consumption scenario, user policy information, merchant identifier, user identifier, order amount, order time, and payment channel to form an order routing result. The order routing result serves as input data for S300. The merchant type and consumption scenario in the order routing result are used by S300 to read the merchant rebate ratio and revenue sharing template. The order amount in the order routing result is used by S300 to calculate the revenue sharing amount. The user policy information in the order routing result is used by S300 to generate revenue sharing calculation results related to premium increases. After the order routing result is generated, the order routing engine writes it into the processing record of the business logic layer and transmits it to the rule configuration center.

[0083] In summary, this step transforms the order request data packet obtained by S100 into an order routing result containing merchant type, consumption scenario, and user policy information. This step centralizes merchant identification, online / offline identification, and user policy information identification within the order routing engine, providing clear input for S300 when subsequently reading merchant rebate ratios and revenue sharing templates. The order routing result generated in this step is then fed into S300, supporting the generation of revenue sharing calculation results.

[0084] S300. Based on the order routing results, perform merchant rebate ratio, revenue sharing template reading and revenue sharing amount calculation to obtain revenue sharing calculation results;

[0085] This step follows the order routing result generated by S200, and is read and calculated by the rule configuration center in the business logic layer. The order routing result is the input data for this step, containing merchant type, consumption scenario, user policy information, merchant identifier, user identifier, order amount, order time, and payment channel. The rule configuration center is a processing module in the business logic layer that stores merchant rebate ratios and revenue sharing templates. The merchant rebate ratio is the calculation parameter for the consumption incentive amount corresponding to the merchant identifier. The revenue sharing template is the amount splitting rule between the payment institution interface, bank custody interface, and insurance core interface. The revenue sharing amount calculation process is the process of generating a revenue sharing calculation result based on the order amount, merchant rebate ratio, revenue sharing template, and user policy information. The revenue sharing calculation result is the input data for the subsequent S400 process instance creation.

[0086] Specifically, after receiving the order routing result, the rule configuration center first reads the merchant identifier and the merchant type, and then searches for the corresponding merchant rebate ratio in the hot merchant configuration. The hot merchant configuration includes merchant access information, merchant rebate ratio association records, and revenue sharing strategy association records for high-frequency consumption merchants. After reading the merchant rebate ratio, the rule configuration center reads the consumption scenario and the payment channel, and searches for the revenue sharing template corresponding to the consumption scenario and the payment channel. The revenue sharing template includes real-time revenue sharing data generation rules for payment institution interfaces, fund freezing or transfer data generation rules for bank custody interfaces, and premium addition data generation rules for insurance core interfaces. If the hot merchant configuration contains the merchant rebate ratio and revenue sharing template corresponding to the merchant identifier, the rule configuration center writes the reading result into the processing record. If the hot merchant configuration does not contain the corresponding content, the rule configuration center marks the order routing result as pending processing and records the missing merchant identifier, merchant type, consumption scenario, and payment channel.

[0087] Further, the rule configuration center reads the user's policy information and verifies the user identifier, policy status, and premium increase association information within the policy information. The user identifier corresponds to the user identifier in the order routing result. The policy status determines whether the user's policy information has entered the premium increase data generation process. The premium increase association information is used to generate premium increase data for the insurance core interface. When the aforementioned user identifiers match and the user's policy information is not recorded as pending processing, the rule configuration center continues to calculate the revenue sharing amount. When the aforementioned user identifiers do not match, or the user's policy information is recorded as pending processing, the rule configuration center suspends the revenue sharing amount calculation process and records the order routing result as pending processing.

[0088] Further, the calculation and processing of the revenue sharing amount is performed by the rule configuration center based on the order amount, the merchant rebate ratio, and the revenue sharing template. The order amount comes from the order routing result. The merchant rebate ratio comes from the merchant rebate ratio read by the rule configuration center. The revenue sharing template comes from the revenue sharing template read by the rule configuration center. The rule configuration center first obtains the consumption incentive amount based on the order amount and the merchant rebate ratio, and then organizes the consumption incentive amount into real-time revenue sharing data for the payment institution interface, fund freeze or transfer data for the bank custody interface, and premium addition data for the insurance core interface according to the revenue sharing template. The real-time revenue sharing data for the payment institution interface includes merchant identifier, user identifier, order amount, consumption incentive amount, and payment channel. The fund freeze or transfer data for the bank custody interface includes user identifier, consumption incentive amount, order time, and payment channel. The premium addition data for the insurance core interface includes user identifier, policy status, premium addition association information, and consumption incentive amount.

[0089] Furthermore, when the merchant rebate ratio or the revenue sharing template undergoes a hot update, the rule configuration center writes the updated merchant rebate ratio and revenue sharing template into the hot merchant configuration. For newly generated order request data packets after the hot update, the rule configuration center reads and calculates the revenue sharing amount based on the updated merchant rebate ratio and revenue sharing template. For order request data packets for which a process instance has already been created, the rule configuration center processes the status nodes according to the merchant rebate ratio and revenue sharing template corresponding to the creation of the process instance. Understandably, the hot update is triggered by the rule configuration center, and the triggering condition is a change in the merchant rebate ratio or a change in the revenue sharing template. After the hot update is completed, the rule configuration center writes the corresponding merchant identifier, merchant type, consumption scenario, and payment channel into the processing record for subsequent reading.

[0090] In one technical solution, the rule configuration center directly reads the merchant rebate ratio and the revenue sharing template from the hot merchant configuration and performs revenue sharing amount calculation. In another technical solution, the rule configuration center first reads the general revenue sharing template according to the merchant type, then reads the corresponding merchant rebate ratio according to the consumption scenario, and combines the two to perform revenue sharing amount calculation. In yet another technical solution, the rule configuration center first reads the user's policy information, then reads the merchant rebate ratio and revenue sharing template; when the user's policy information is recorded as pending processing, the rule configuration center stops generating premium addition data for the insurance core interface and records the order routing result as pending processing.

[0091] Understandably, in actual operation scenarios, after offline merchants submit consumption orders through POS machines, the order routing results generated by S200 record the offline consumption scenario, merchant type, user policy information, order amount, and payment channel. After receiving the order routing results, the rule configuration center reads the merchant rebate ratio corresponding to the merchant type and the revenue sharing template corresponding to the offline consumption scenario. Subsequently, the rule configuration center obtains the consumption incentive amount based on the order amount and merchant rebate ratio, and generates real-time revenue sharing data for the payment institution interface, fund freezing or transfer data for the bank custody interface, and premium addition data for the insurance core interface according to the revenue sharing template. For order routing results submitted by e-commerce platforms or mobile apps, the rule configuration center reads the corresponding revenue sharing template based on the online consumption scenario and generates revenue sharing calculation results according to the same processing link.

[0092] Furthermore, the revenue sharing calculation result consists of merchant identifier, user identifier, order amount, order time, payment channel, merchant rebate ratio, revenue sharing template, consumption incentive amount, real-time revenue sharing data from the payment institution interface, fund freeze or transfer data from the bank custody interface, and premium increase data from the insurance core interface. The rule configuration center writes the revenue sharing calculation result into the processing record of the business logic layer and transmits it to S400. S400 performs process instance creation and consumption, revenue sharing, custody, and insurance status node setting processing based on the revenue sharing calculation result to obtain the process instance status.

[0093] In summary, the technical effects of this step are as follows: This step converts the order routing results obtained from S200 into a revenue-sharing calculation result that includes the data required by the payment institution interface, bank custody interface, and insurance core interface. This step incorporates merchant rebate ratios, revenue-sharing templates, and user policy information into the same calculation chain, forming a unified processing result before consumer orders enter the revenue-sharing, custody, and insurance status nodes. The revenue-sharing calculation result generated in this step enters S400, supporting the generation of process instance status.

[0094] S400. Based on the revenue sharing calculation result, perform process instance creation and consumption, revenue sharing, custody, and insurance status node setting processing to obtain the process instance status;

[0095] This step follows the revenue sharing calculation result generated by S300, and is processed by the workflow engine in the business logic layer, which executes the creation of process instances and the setting of status nodes. The revenue sharing calculation result is the input data for this step, and includes merchant identifier, user identifier, order amount, order time, payment channel, merchant rebate ratio, revenue sharing template, consumption incentive amount, real-time revenue sharing data from the payment institution interface, fund freeze or transfer data from the bank custody interface, and premium addition data from the insurance core interface. The workflow engine is a processing module in the business logic layer that records and advances the consumption, revenue sharing, custody, and insurance status nodes. The process instance is a status record generated around an order request data packet and a set of revenue sharing calculation results. The process instance status is a combination of the current status, node order, and processed data of the process instance in the consumption status node, revenue sharing status node, custody status node, and insurance status node.

[0096] Specifically, after receiving the revenue sharing calculation result, the workflow engine first reads the merchant identifier, the user identifier, the order amount, the order time, and the payment channel, and uses these as the basic fields for creating the process instance. The workflow engine then reads the consumption incentive amount, the real-time revenue sharing data from the payment institution interface, the fund freeze or transfer data from the bank custody interface, and the premium increase data from the insurance core interface, and uses these as the processing data for setting the status node. When both the aforementioned basic fields and the aforementioned processing data exist, the workflow engine creates a process instance and establishes a correspondence between the process instance and the order request data packet generated in S100, the order routing result generated in S200, and the revenue sharing calculation result generated in S300. When either of the aforementioned basic fields or the aforementioned processing data is missing, the workflow engine does not proceed to the status node setting process and records the revenue sharing calculation result as pending processing.

[0097] Furthermore, the workflow engine sets up consumption status nodes, revenue sharing status nodes, custody status nodes, and insurance status nodes in the process instance. The consumption status node records the merchant identifier, user identifier, order amount, order time, and payment channel from the order request data packet and the revenue sharing calculation result. The revenue sharing status node records the consumption incentive amount from the revenue sharing calculation result and the real-time revenue sharing data from the payment institution interface. The custody status node records the fund freeze or transfer data from the bank custody interface and receives the bank custody status in subsequent S500. The insurance status node records the premium increase data from the insurance core interface and receives the premium increase result in subsequent S500. The workflow engine writes the node records in the order of consumption status nodes, revenue sharing status nodes, custody status nodes, and insurance status nodes.

[0098] Furthermore, the workflow engine sets the state transition results for each state node. The initial state of the consumption state node is generated based on the order request data packet and the revenue sharing calculation result. The revenue sharing state node uses the state transition result of the consumption state node as processing data. The custodian state node uses the state transition result of the revenue sharing state node as processing data. The insurance state node uses the state transition result of the custodian state node as processing data. Each state node records input data, node status, processing data, and the next state node. The input data is the data entering this state node. The node status is one of pending processing, processing, or processed. The processing data is the data transmitted from this state node to the next state node. The next state node is the state node entered after the current state node has completed processing.

[0099] Furthermore, the workflow engine records the connection relationships between status nodes during the process instance creation process. The consumption status node connects to the revenue sharing status node, the revenue sharing status node connects to the custody status node, and the custody status node connects to the insurance application status node. The workflow engine reads the revenue sharing template and writes the execution order of the payment institution interface, bank custody interface, and insurance core interface in the revenue sharing template into the process instance. The real-time revenue sharing data of the payment institution interface corresponds to the revenue sharing status node. The fund freeze or transfer data of the bank custody interface corresponds to the custody status node. The premium addition data of the insurance core interface corresponds to the insurance application status node. After the status node connection relationships are completed, the workflow engine generates the process instance status.

[0100] In one technical solution, when creating the process instance, the workflow engine writes the order request data packet, the order routing result, and the revenue sharing calculation result into the processing record of the same process instance. The consumption status node reads the merchant identifier, user identifier, order amount, order time, and payment channel from the order request data packet. The revenue sharing status node reads the consumption incentive amount and real-time revenue sharing data from the payment institution interface from the revenue sharing calculation result. The custody status node reads the fund freeze or transfer data from the bank custody interface from the revenue sharing calculation result. The insurance status node reads the premium increase data from the insurance core interface from the revenue sharing calculation result. In this technical solution, the workflow engine completes data transfer between status nodes through the same processing record.

[0101] In another technical solution, after creating the process instance, the workflow engine writes the consumption status node, the revenue sharing status node, the custody status node, and the insurance application status node into the status record of the business logic layer. The status record stores the node status and processing data of each status node. Before the revenue sharing status node starts, the workflow engine reads the status transition result of the consumption status node. Before the custody status node starts, the workflow engine reads the status transition result of the revenue sharing status node. Before the insurance application status node starts, the workflow engine reads the status transition result of the custody status node. In this technical solution, status nodes are passed down level by level through status records.

[0102] Understandably, in actual operation scenarios, after offline merchants submit consumption orders through POS machines, the revenue sharing calculation result generated by S300 includes real-time revenue sharing data from the payment institution interface, fund freezing or transfer data from the bank custody interface, and premium addition data from the insurance core interface. After reading the revenue sharing calculation result, the workflow engine creates a process instance corresponding to the consumption order. The workflow engine first sets a consumption status node and writes the order request data packet and the revenue sharing calculation result into this node. Then, the workflow engine sets a revenue sharing status node and writes the real-time revenue sharing data from the payment institution interface into this node. Next, the workflow engine sets a custody status node and writes the fund freezing or transfer data from the bank custody interface into this node. Finally, the workflow engine sets an insurance status node and writes the premium addition data from the insurance core interface into this node. After the process instance is created, the process instance status enters S500, serving as input for real-time revenue sharing from the payment institution interface, fund freezing or transfer from the bank custody interface, and policy query and premium addition processing from the insurance core interface.

[0103] Furthermore, the process instance status consists of a process instance, a consumption status node, a revenue sharing status node, a custody status node, an insurance status node, a node sequence record, and a status transition result. Within the process instance status, the consumption status node records the order request data packet, the revenue sharing status node records the revenue sharing calculation result, the custody status node records the bank custody status returned by S500, and the insurance status node records the premium addition result returned by S500. The workflow engine writes the process instance status into the processing record of the business logic layer and transmits the process instance status to S500. Based on the process instance status, S500 performs real-time revenue sharing at the payment institution interface, fund freezing or transfer at the bank custody interface, and policy query and premium addition processing at the insurance core interface, obtaining the interface execution status.

[0104] In summary, the technical effects of this step are as follows: This step transforms the revenue sharing calculation results obtained from S300 into process instance states with consumption, revenue sharing, custody, and insurance status nodes. This step binds the processing data from the payment institution interface, bank custody interface, and insurance core interface to their respective status nodes, forming a continuous state transition chain. The process instance states generated in this step enter S500, supporting the generation of interface execution states.

[0105] In one specific embodiment:

[0106] In S400, based on the revenue sharing calculation results, process instance creation and consumption, revenue sharing, custody, and insurance status node settings are performed to obtain the process instance status.

[0107] The workflow engine in the business logic layer receives the revenue sharing calculation results generated by S300, which includes the merchant identifier. User ID Order amount Order time Payment channels Merchant rebate ratio Profit sharing template Consumption incentive amount Real-time revenue sharing data from payment institution interfaces Data on fund freezing or transfer via bank custody interface And premium addition data from the core insurance interface The workflow engine first extracts the basic field from the revenue sharing calculation results: Merchant Identifier. User ID Order amount Order time Payment channels Simultaneously extract and process the following data: consumption incentive amount. Real-time revenue sharing data Data on frozen or transferred funds Additional premium data To determine whether the above data is sufficient to support the creation of a complete process instance, the workflow engine constructs a completeness judgment function, which maps basic fields and processing data to an instance creation feasibility score. Formula ① defines this judgment process.

[0108] Formula①

[0109]

[0110] in:

[0111] Instance creation feasibility score, value range ;

[0112] : Multiplication symbol, indicating multiplication by multiplication arrive The product;

[0113] Integer index, with a value of This corresponds to five basic fields;

[0114] : Indicator function, takes any field as input, and outputs if the field is not empty and has a valid data type. Otherwise output ;

[0115] : No. The basic fields are as follows: (Merchant identifier, string) (User ID, string) (Order amount, unit: yuan) (Order time, Unix timestamp, unit: seconds) (Payment channels, enumeration values);

[0116] The minimum value function returns the smaller of the two expressions within the parentheses;

[0117] : Summation symbol, indicating summation of... arrive The accumulation;

[0118] Integer index, with a value of This corresponds to four data fields for processing;

[0119] : No. Each data processing weighting coefficient is dimensionless and is determined by the workflow engine based on the revenue sharing template. The interface priority is dynamically set, with a value range of... and ;

[0120] : No. One data field to be processed, specifically: (Consumption incentive amount, unit: yuan) (Real-time revenue sharing data from payment institution interfaces, in a structure). (Data on frozen or transferred funds through the bank custody interface, in a structure). (Insurance core interface premium addition data, structure);

[0121] denominator The sum of all weights, since it has been normalized, is always equal to .

[0122] Data Source → Metrics → Variable Mapping: Extracting Order Amount from Revenue Sharing Calculation Results and consumption incentive amount Then, the interface priority list is extracted from the revenue sharing template and normalized to obtain... Together they form the formula ① .

[0123] Simple numerical example: Assuming the order amount Yuan, consumption incentive amount If all basic fields are valid, then... If all the data being processed exists... denominator min=1, therefore If bank custody data is missing ( )and Therefore, the numerator = 0.4 + 0 + 0.25 = 0.65, and the min = 0.65. .

[0124] when At that time, the workflow engine creates a process instance and establishes a correspondence between this instance and the order request data packet, order routing results, and revenue sharing calculation results. If the calculation result is not found, the revenue sharing calculation result will be marked as pending and this step will be terminated. After creating the instance, the workflow engine needs to determine the setting order of the four status nodes: consumption, revenue sharing, custody, and insurance. Since there are causal dependencies between the four nodes (the revenue sharing node can only start after the consumption node is completed, and so on), the workflow engine uses a topological sorting algorithm to solidify the node order. Formula ② calculates the dependency strength matrix between nodes to verify the uniqueness of the dependency relationship.

[0125] Formula②

[0126]

[0127] in:

[0128] : Dependency strength between adjacent state nodes, range of values ;

[0129] Integer index, with a value of Each corresponds to a consumption node. Revenue Sharing Nodes Custody Node Implicit This is the point at which insurance is purchased;

[0130] : No. There are 1 state node, among which For consumption status nodes, For the revenue sharing status node, This is a node for storing data in a custodian state. This is the insurance status node;

[0131] The cardinality function for a set returns the number of elements in the set.

[0132] :node The required input data set is taken from the field set in the revenue sharing calculation results, for example... , wait;

[0133] Set intersection operation;

[0134] : Minimal positive number, take This is used to prevent the denominator from being zero;

[0135] : Dependency indicator function, if node The input data depends on the node The output data is Otherwise .

[0136] Data Source → Metrics → Variable Mapping: Based on the account splitting template in the account splitting calculation results. Extract the interface order relationship and map it as ; mapped from the field list of each state node to , thus calculating .

[0137] Simple numerical example: Retrieving consumer nodes Revenue sharing node The intersection of the two sets is empty, but it depends on the indicator function. (Because the revenue sharing node needs the consumer node to have recorded the order data), the numerator is 0, and the denominator is... , In fact, a dependency can still be established even if the dependency strength is 0, because the indicator function has already guaranteed the existence of the dependency.

[0138] The engineering purpose of Formula ② is to check whether there are conflicts in dependencies. and When it represents a purely logical dependency, a connection can be established; if but Then you need to call the police.

[0139] The workflow engine verifies the correctness of the node order based on the output of formula ②. Once verification is successful, the workflow engine proceeds according to... The data is written sequentially to the node's sequential record, and the basic fields and processing data are bound to the corresponding nodes respectively. The consumption status node records the data in the order request data packet. Revenue sharing status node record and Storage status node record Insurance status node record The output of this step is a preliminary process instance framework, which includes node sequence records and field binding relationships. This framework is used as the basic input for the "process instance status" by the workflow engine in the S500 step.

[0140] Following the above-mentioned sequential recording and field binding of nodes, the workflow engine needs to set the state transition results for each state node, that is, define the initial node state of each node (pending / processing / processed) and the data transfer relationships between nodes. To this end, the workflow engine constructs a state transition matrix, the first of which is... Line 1 Column elements represent the nodes To the node The allowed transition probability. Since the node order is fixed as a linear chain, the transition probability only changes when... The time is non-zero. Formula ③ defines the node. The activation condition function determines whether a node can move from being pending to being processed. (Formula ③)

[0141]

[0142] in:

[0143] :node The activation coefficient, in practice, takes the value of or (Because the exponent term is 1 when the deviation is zero and close to 0 when it is non-zero, it is forced to be 0 in conjunction with the preceding indicator).

[0144] : Predecessor node success indicator function, if node If the process has been completed and its state transition result is successful, then take... Otherwise take ;

[0145] Integer index, here ,Right now This corresponds to the accounting, custody, and insurance stages;

[0146] Natural exponential function ;

[0147] : Norm, ,in These are the components of the deviation vector;

[0148] : The deviation vector between the output of the predecessor node and the expected input of the current node, for example, for a revenue sharing node. , (A one-dimensional vector, at this time) );

[0149] :node The tolerance scale parameter, with the same unit as the deviation (e.g., yuan), is read by the workflow engine based on the fault tolerance configuration of the interface in the revenue sharing template.

[0150] Data Source → Metrics → Variable Mapping: Consumption incentive amount from the revenue sharing calculation results Order amount Merchant rebate ratio Calculate the deviation The interface timeout configuration in the revenue sharing template is mapped to... .

[0151] Simple numerical examples: Yuan, ,but Yuan, Yuan, deviation Yuan, Yuan, with an exponent of 1. Therefore .like Yuan, then Yuan, exponent term , The node is not activated.

[0152] Activation coefficient This determines whether a node enters the processing state. For an activated node, the workflow engine needs to transmit its processing data (i.e., the interface data extracted from the revenue sharing calculation results) to the next node. The transmission process is controlled by the data transfer efficiency function in Formula ④ to ensure data integrity and correct sequence. Formula ④

[0153]

[0154] in:

[0155] :node Data transmission efficiency, value range ;

[0156] : Summation symbol, for arrive Accumulation;

[0157] Integer index, representing the field sequence number;

[0158] :node The total number of data fields that need to be passed to the next node for processing (i.e., the number of output fields).

[0159] : Field integrity check function. If the input field is not empty and the format conforms to the accounting template convention, then output the correct field. Otherwise output ;

[0160] :node The Each output field comes from the processed data bound to that node in the revenue sharing calculation result (e.g., ...). (the subfields that have been decomposed)

[0161] : Activation coefficient from formula ③.

[0162] Data Source → Metrics → Variable Mapping: Real-time revenue sharing data from the payment institution interface in the revenue sharing calculation results. Decompose into subfields, and map each subfield to a... ; Defined by the field validation rules of the workflow engine .

[0163] Simple numerical example: For a revenue sharing node , It contains three subfields: Merchant ID (valid), User ID (valid), and Incentive Amount of 5.00 Yuan (valid). ,so , If the consumption incentive amount is missing, then twice, .

[0164] The workflow engine sets the node status (pending, processing, processed) of each status node based on the results of formulas ③ and ④. Specifically, when The time node status is set to pending; when and When the node status is set to "processed", the processed data is written to the node record; when and The time node status is set to "processing" and a data completion request is triggered.

[0165] After the above processing, the workflow engine generates a state transition result that includes the status of each node, the processed data, and the node sequence record.

[0166] Furthermore, the workflow engine reads the interface execution order from the revenue sharing template, associates the payment institution interface with the revenue sharing status node, the bank custody interface with the custody status node, and the insurance core interface with the insurance application status node, and writes these associations into the processing record of the process instance. The output of this step is the process instance status, which is determined by the process instance identifier, the consumption status node record (order request data packet), and the revenue sharing status node record (found in the revenue sharing calculation result). and ), storage status node records ( ), Insurance status node record ( ), Node Sequence Records ( This process instance's state is composed of the status transition results (processed / pending / processing) of each node. The workflow engine in the S500 steps uses this status as input for calling payment, banking, and insurance interfaces.

[0167] Following the flow of state transitions between process instances and nodes, the workflow engine also needs to perform consistency checks on the overall state of the process instances and pre-generate call sequences for subsequent S500 interface calls. To this end, the workflow engine constructs a state space vector, which includes the activation flag of each node, data transmission efficiency, and the causal coupling strength between nodes.

[0168] Formula ⑤ integrates the above indicators into a single process instance health score, used to determine whether the instance can enter the S500 for execution. Formula ⑤

[0169]

[0170] in:

[0171] Process instance health status, value range ;

[0172] : Multiplication symbol, for arrive Find the product. In practical engineering... (Consumer node weight) This often results in a product of 0, so it is skipped in practice. );

[0173] Integer index, This corresponds to four state nodes;

[0174] :node The importance weight is determined by the amount of funds in the interface of the revenue sharing template, satisfying... (Typical consumption nodes) );

[0175] : Data transfer efficiency from formula ④;

[0176] : Activation coefficient from formula ③;

[0177] : Causal coupling coefficient, taking values ​​of or If node The failure of this will cause subsequent nodes to be unable to execute. Otherwise Because the four nodes are linearly dependent, all .

[0178] Data Source → Metrics → Variable Mapping: Mapping the amount of funds in the revenue sharing template to... Substitute the results from formulas ③ and ④ into formula ⑤.

[0179] Simple numerical example: Assume a consumer node The first item is The entire product is 0. This occurs if the consumer node weight is set to 0. This is unreasonable. Therefore, in actual engineering, the consumption node does not participate in the product, and formula ⑤ should be revised to... .Pick Set up revenue sharing nodes Custody Node Insurance application deadline Then each term is 0.4, 0.35, and 0.25 respectively, and the product is... This value is for comparison only. The actual health threshold is set to 0.03, so 0.035 > 0.03, and the instance is qualified.

[0180] when When the value exceeds a preset threshold, the workflow engine considers the process instance state valid and allows it to proceed to the interface call phase. Subsequently, the workflow engine needs to generate an ordered sequence of interface calls for the S500. Since there are multiple external interfaces and the call order must match the state node order, the workflow engine uses the priority vector shown in Formula ⑥ to map the startup conditions for each interface. Formula ⑥

[0181]

[0182] in:

[0183] Interface call priority vector, column vector, components All are Boolean values ​​( or );

[0184] : No. The call permission flag for each interface. These correspond to the payment institution interface, bank custody interface, and insurance core interface, respectively.

[0185] Integer index, retrieve ;

[0186] : Multiplication symbol, for arrive Find the product;

[0187] Integer index, representing the interface sequence number;

[0188] : Interface ready indicator function, when the first Each status node (corresponding to the revenue sharing node) The corresponding storage node Insurance application period corresponding to The node status is "processed" and its output data is complete. Time to take Otherwise take ;

[0189] : Matrix transpose symbol, converts a row vector into a column vector.

[0190] Data Source → Metrics → Variable Mapping: Mapping the node status of the revenue sharing status node in the process instance status to... The node state of the storage state node is mapped to... The node status of the insured status node is mapped to... .

[0191] Simple numerical example: If the revenue sharing node is already processed... If the storage node is in the process of processing... ,but , , This indicates that only the payment interface can be called; the banking and insurance interfaces will wait.

[0192] The workflow engine will use the components obtained from formula ⑥ Write the "Interface Call Mask" field to the process instance status, and then enter the complete process instance status (including health). The node sequence record, node status, and processing data are transmitted to S500. At this point, step S400 is complete.

[0193] This section summarizes the technical effects: This step transforms the revenue sharing calculation results into process instances with clear causal dependencies. Through the judgment and mapping of formulas ① to ⑥, it achieves automatic creation of state nodes, integrity verification, activation control, and pre-generation of interface call sequences, providing a traceable and verifiable state foundation for subsequent distributed transaction compensation. Unlike ordinary workflow engines that only record task states, this step integrates interface data load with state nodes and solidifies the mandatory order between nodes through causal coupling coefficients, fundamentally avoiding disordered processing order of funds and policies.

[0194] S500. Based on the state of the process instance, perform real-time accounting for payment institution interfaces, freezing or transferring funds for bank custody interfaces, and processing policy inquiries and premium additions for insurance core interfaces to obtain the interface execution status.

[0195] This step follows the process instance state generated by S400. The business logic layer processes the calls to the interfaces according to the consumption status node, accounting status node, custody status node, and insurance status node in the process instance state. The process instance state is the input data for this step, recording the process instance, order request data packet, accounting calculation result, consumption status node, accounting status node, custody status node, insurance status node, node sequence record, and status transition result. The payment institution interface is the interface in the external interface layer that receives real-time accounting data and returns accounting results. The bank custody interface is the interface in the external interface layer that receives fund freezing or transfer data and returns the bank custody status. The insurance core interface is the interface in the external interface layer that receives user policy information and premium addition data and returns policy query results and premium addition results. The interface execution status is a combined record of the accounting result, the bank custody status, and the premium addition result, and serves as the input for S600 to perform failure, timeout, or processing overdue judgment and Saga mode compensation processing.

[0196] Specifically, the workflow engine reads the state of the process instance and first verifies the state transition result of the consumption state node. The consumption state node records the order request data packet and the revenue sharing calculation result. When the aforementioned consumption state node is in the processed state, the workflow engine reads the real-time revenue sharing data from the payment institution interface in the revenue sharing state node and calls the payment institution interface to perform real-time revenue sharing processing. The real-time revenue sharing data includes merchant identifier, user identifier, order amount, consumption incentive amount, and payment channel. After receiving the real-time revenue sharing data, the payment institution interface verifies the merchant identifier, payment channel, and consumption incentive amount, and then returns the revenue sharing result. The revenue sharing result includes a success, failure, timeout, or processing status, and records the merchant identifier, user identifier, order amount, consumption incentive amount, payment channel, and interface return time.

[0197] Furthermore, when the revenue sharing result is successful, the workflow engine writes the revenue sharing result to the revenue sharing status node and transmits the status flow result of the revenue sharing status node to the custody status node. The custody status node reads the revenue sharing result and the fund freeze or transfer data of the bank custody interface. The fund freeze or transfer data of the bank custody interface includes user identifier, consumption incentive amount, order time, and payment channel. The workflow engine calls the bank custody interface based on the revenue sharing result to perform fund freeze or transfer processing. After receiving the fund freeze or transfer data, the bank custody interface performs user identifier verification, consumption incentive amount verification, order time verification, and payment channel verification, and then returns the bank custody status. The bank custody status includes fund freeze status, fund transfer status, failure, timeout, or processing status, and records user identifier, consumption incentive amount, order time, payment channel, and interface return time.

[0198] Furthermore, when the bank custody status is "funds successfully frozen" or "funds successfully transferred," the workflow engine writes the bank custody status to the custody status node and transmits the status flow result of the custody status node to the insurance status node. The insurance status node reads the premium addition data and the user's policy information from the insurance core interface. The premium addition data includes the user identifier, policy status, premium addition association information, and consumption incentive amount. The insurance core interface first performs a policy query based on the user identifier and the policy status to obtain the policy query result. When the aforementioned policy query result is successful, the insurance core interface performs premium addition processing based on the premium addition association information and the consumption incentive amount, and returns the premium addition result. The premium addition result includes a success, failure, timeout, or processing status, and records the user identifier, policy status, premium addition association information, consumption incentive amount, and interface return time.

[0199] Understandably, when the payment institution interface returns a failure, timeout, or processing status, the workflow engine writes the revenue sharing result to the interface execution status and marks the custody status node and the insurance status node as pending. In this case, the bank custody interface and the insurance core interface are not invoked in this step. When the payment institution interface returns success and the bank custody interface returns a failure, timeout, or processing status, the workflow engine writes the bank custody status to the interface execution status and marks the insurance status node as pending. In this case, the insurance core interface is not invoked in this step. When the payment institution interface returns success, the bank custody interface returns successful fund freezing or successful fund transfer, and the insurance core interface returns a failure, timeout, or processing status, the workflow engine writes the premium addition result to the interface execution status and retains the revenue sharing result and the bank custody status for S600 to read.

[0200] In technical solution one, the workflow engine synchronously calls the payment institution interface, the bank custody interface, and the insurance core interface in the order of the accounting status node, custody status node, and insurance status node. In this technical solution, after the previous interface returns a successful response, the workflow engine immediately calls the next interface and writes the return result of the previous interface into the processing data of the next status node. In technical solution two, the workflow engine records the processing status of the return results of the payment institution interface, the bank custody interface, and the insurance core interface. When the interface returns a processing status, the workflow engine records the processing status and the interface return time in the process instance status and transmits the processing status to the interface execution status. In technical solution three, after the interface returns a timeout, the workflow engine does not create a new process instance, but writes a timeout status into the original process instance and transmits the timeout status to S600.

[0201] In actual operation scenarios, after a user completes a transaction via a mobile app, the S400-generated process instance already has a transaction status node, a revenue sharing status node, a custody status node, and an insurance application status node set. The workflow engine first reads the real-time revenue sharing data from the revenue sharing status node and calls the payment institution interface. After the payment institution interface returns a successful revenue sharing result, the workflow engine reads the fund freeze or transfer data from the custody status node and calls the bank custody interface. After the bank custody interface returns a successful fund transfer, the workflow engine reads the user's policy information and premium increase data from the insurance application status node and calls the insurance core interface. After the insurance core interface returns the premium increase result, the workflow engine combines the revenue sharing result, the bank custody status, and the premium increase result into an interface execution status and writes this interface execution status into the processing record of the business logic layer.

[0202] Furthermore, the interface execution status consists of the process instance, revenue sharing result, bank custody status, policy query result, premium addition result, interface return time, and the correspondence between status nodes. The revenue sharing result corresponds to the revenue sharing status node, the bank custody status corresponds to the custody status node, and the policy query result and the premium addition result correspond to the insurance application status node. The workflow engine transmits the interface execution status to S600. S600 performs failure, timeout, or processing overdue judgment and Saga mode compensation processing based on the interface execution status to obtain the compensation process result.

[0203] The technical effects of this step can be summarized as follows: This step transforms the process instance state obtained from S400 into an interface execution state that includes the revenue sharing result, bank custody status, and premium increase result. This step completes the continuous calls to the payment institution interface, bank custody interface, and insurance core interface in the order of revenue sharing status node, custody status node, and insurance application status node. The interface execution state generated in this step enters S600, supporting failure, timeout, or processing overdue judgment and Saga mode compensation processing.

[0204] S600. Based on the execution status of the interface, perform failure, timeout, or processing timeout judgment and Saga mode compensation processing to obtain the compensation process result.

[0205] This step follows the interface execution status generated by S500. The workflow engine in the business logic layer reads the interface execution status and determines whether it is a failure, timeout, or processing overdue. The interface execution status is the input data for this step, and it includes the process instance, accounting result, bank custody status, policy query result, premium addition result, interface return time, and the correspondence between status nodes. A failure occurs when the payment institution interface, bank custody interface, or insurance core interface returns a failed status. A timeout occurs when the interface call fails to return a result within the set processing time. A processing overdue occurs when the processing time exceeds the processing time recorded in the process instance after the interface returns to the processing status. The Saga mode is a cross-system long transaction processing mode. The compensation process involves performing refunds, unfreezing, reverse transfers, premium addition result queries, or marking processes as pending based on completed status nodes. The compensation process result is the output data for this step and is transmitted to S700 for key transaction hash generation and blockchain evidence node writing.

[0206] Specifically, the workflow engine first reads the settlement result from the interface execution status and determines whether the settlement result is successful, failed, timed out, or overdue during processing. The settlement result comes from the payment institution interface and corresponds to the settlement status node in the process instance. When the settlement result is failed, timed out, or overdue during processing, the workflow engine records the settlement status node as pending and stops reading the bank custody status and premium addition result. At this time, the compensation process result record includes the process instance, settlement result, settlement status node, pending processing flag, and interface return time. When the aforementioned settlement result is successful, the workflow engine continues to read the bank custody status and enters the judgment and processing of the custody status node.

[0207] Further, the workflow engine reads the bank custody status and determines whether the bank custody status is successful (funds frozen successfully), successful (funds transferred successfully), failed, timed out, or overdue (processing in progress). The bank custody status comes from the bank custody interface and corresponds to the custody status node in the process instance. When the settlement result is successful and the bank custody status is failed, timed out, or overdue (processing in progress), the workflow engine starts the compensation process according to the Saga mode and processes the refund or marks it as pending based on the settlement result recorded in the settlement status node. When processing the refund, the workflow engine reads the merchant identifier, user identifier, order amount, consumption incentive amount, and payment channel from the process instance and writes these fields into the refund record. When marked as pending, the workflow engine writes the process instance, the settlement result, and the bank custody status into the pending record. After completing the above processing, the workflow engine generates a compensation process result containing either the refund record or the pending record.

[0208] Furthermore, when the bank custody status is "funds successfully frozen," the workflow engine reads the policy query result and determines whether the policy query result is successful, failed, timed out, or overdue during processing. The policy query result comes from the insurance core interface and corresponds to the insurance status node in the process instance. When the funds freeze status is successful and the policy query result is failed, timed out, or overdue during processing, the workflow engine executes the unfreezing process according to the Saga mode. During the unfreezing process, the workflow engine reads the user identifier, consumption incentive amount, order time, and payment channel from the custody status node and writes these fields into the unfreezing record. After completing the unfreezing process, the workflow engine writes the unfreezing record, the policy query result, and the process instance into the compensation process result.

[0209] Furthermore, when the bank custody status indicates successful fund transfer, the workflow engine reads the premium addition result and determines whether the premium addition result is successful, failed, timed out, or overdue during processing. The premium addition result comes from the insurance core interface and corresponds to the insurance status node in the process instance. When the fund transfer status is successful and the premium addition result is failed, timed out, or overdue during processing, the workflow engine executes reverse transfer, premium addition result query, or marks it as pending processing according to the Saga mode. During reverse transfer processing, the workflow engine reads the user identifier, consumption incentive amount, order time, and payment channel from the custody status node and writes them into the reverse transfer record. During premium addition result query processing, the workflow engine reads the user identifier, policy status, premium addition related information, and consumption incentive amount from the insurance status node and writes them into the premium addition result query record. When marked as pending processing, the workflow engine writes the process instance, the bank custody status, and the premium addition result into the pending processing record.

[0210] Understandably, in actual operation scenarios, after a user completes a transaction through a mobile app, the S500 returns an interface execution status that records the settlement result, bank custody status, and premium payment result. If the payment institution interface returns a successful settlement result, the bank custody interface returns a successful fund transfer, but the insurance core interface returns a premium payment result indicating a timeout, the workflow engine reads the insurance status node in the process instance and initiates Saga mode compensation processing. The workflow engine first performs a premium payment result query. If the query still records a timeout in processing, the workflow engine generates a reverse transfer record or a pending record based on the fund transfer status. Subsequently, the workflow engine writes the process instance, settlement result, bank custody status, premium payment result, reverse transfer record, or pending record into the compensation process result.

[0211] In technical solution one, the workflow engine immediately determines failure, timeout, or processing overdue status after the interface execution status is generated, and generates a compensation process result within the same process instance. In technical solution two, the workflow engine first writes the processing status to the process instance, then determines processing overdue based on the interface return time, and generates a compensation process result when the processing overdue period is reached. In technical solution three, the workflow engine directly generates a pending record for failure status, performs a premium addition result query for timeout status, and reverses or marks processing overdue status as pending.

[0212] Furthermore, the compensation process result consists of a process instance, a revenue sharing result, a bank custody status, a policy query result, a premium increase result, a refund record, an unfreezing record, a reverse transfer record, a premium increase result query record, a pending record, and a compensation processing time. The workflow engine writes the compensation process result into the processing record of the business logic layer and transmits the compensation process result to S700. S700 performs key transaction hash generation and blockchain notarization node writing processing based on the compensation process result to obtain the notarized record.

[0213] The technical effects of this step can be summarized as follows: This step converts the interface execution status obtained from S500 into compensation process results. Based on the completion status of the accounting status node, custody status node, and insurance status node, this step selects whether to query the results of refunds, unfreezing, reverse transfers, premium increases, or mark them as pending. The compensation process results generated in this step are entered into S700, supporting the generation of key transaction hashes and the writing of data to the blockchain evidence storage node.

[0214] S700. Based on the results of the compensation process, perform key transaction hash generation and blockchain evidence storage node writing to obtain evidence storage records.

[0215] This step follows the compensation process result generated by S600. The business logic layer reads the compensation process result and calls the blockchain evidence storage node in the data layer for write processing. The compensation process result is the input data for this step, including the process instance, accounting result, bank custody status, policy query result, premium increase result, refund record, unfreezing record, reverse transfer record, premium increase result query record, pending record, and compensation processing time. The key transaction hash is a hash result generated based on the transaction status field. The blockchain evidence storage node is the node in the data layer that receives the key transaction hash and forms an evidence storage record. The evidence storage record is the output data for this step and is transmitted to S800 as input for Canal to monitor MySQL Binlog and Elasticsearch synchronization.

[0216] Specifically, the workflow engine first reads the process instance from the compensation process result, and then reads the corresponding order request data packet, revenue sharing calculation result, and process instance status based on the process instance. The order request data packet includes merchant identifier, user identifier, order amount, order time, and payment channel. The revenue sharing calculation result includes merchant rebate ratio, revenue sharing template, consumption incentive amount, real-time revenue sharing data from the payment institution interface, fund freeze or transfer data from the bank custody interface, and premium increase data from the insurance core interface. The process instance status includes consumption status node, revenue sharing status node, custody status node, and insurance status node. The workflow engine maps the above data to the fields of the compensation process result to obtain the processing data required for generating the key transaction hash.

[0217] Furthermore, the workflow engine performs field organization on the processed data. This field organization includes organizing merchant identifiers, user identifiers, order amounts, order times, revenue sharing results, bank custody status, premium addition results, compensation process results, and process instance status. The merchant identifier, user identifier, order amount, and order time are derived from the order request data packet. The revenue sharing result is derived from the payment institution interface return result in the interface execution state. The bank custody status is derived from the bank custody interface return result in the interface execution state. The premium addition result is derived from the insurance core interface return result in the interface execution state. The compensation process result is derived from S600. The process instance status is derived from S400. The aforementioned fields constitute the necessary fields for generating the key transaction hash.

[0218] Furthermore, the workflow engine unifies and organizes the status values ​​of the necessary fields. When unifying status values, the workflow engine records success, failure, timeout, overdue processing, pending processing, successful fund freeze, successful fund transfer, successful premium increase, and failed premium increase as a single status field. When organizing the order, the workflow engine arranges the data according to the order of order request data packet, accounting result, bank custody status, premium increase result, compensation process result, and process instance status. If the compensation process result includes a refund record, the workflow engine writes the refund record into the compensation process result field. If the compensation process result includes an unfreezing record, the workflow engine writes the unfreezing record into the compensation process result field. If the compensation process result includes a reverse transfer record, a premium increase result query record, or a pending processing record, the workflow engine writes the corresponding record into the compensation process result field.

[0219] Furthermore, the workflow engine performs key transaction hash generation processing based on the necessary fields after sequential arrangement. During this key transaction hash generation process, the workflow engine reads the merchant identifier, user identifier, order amount, order time, revenue sharing result, bank custody status, premium addition result, compensation process result, and process instance status, and uses these fields as hash processing objects for the same transaction link. The hash processing objects are then hashed to obtain the key transaction hash. The key transaction hash corresponds to the process instance and is written to the processing record of the business logic layer. After the key transaction hash is generated, the workflow engine encapsulates the key transaction hash, the process instance, the compensation process result, and the process instance status into evidence storage data.

[0220] Further, the workflow engine sends the notarization data to the blockchain notarization node. Upon receiving the notarization data, the blockchain notarization node reads the key transaction hash, process instance, and compensation process result, and performs the write process. The write process includes writing the key transaction hash, writing the process instance, writing the compensation process result, and recording the write status. If the blockchain notarization node returns a successful write status, the workflow engine generates a notarization record and writes it to the data layer. If the blockchain notarization node returns a failure, timeout, or processing status, the workflow engine marks the notarization record as pending processing and retains the key transaction hash, the process instance, and the compensation process result.

[0221] In one technical solution, the workflow engine immediately performs key transaction hash generation processing after the compensation process result is generated, and sends the generated key transaction hash to the blockchain evidence storage node. In another technical solution, the workflow engine first writes the compensation process result into the processing record of the business logic layer, and then reads the processing record to perform key transaction hash generation processing. In yet another technical solution, when the blockchain evidence storage node returns to the processing state, the workflow engine retains the key transaction hash and marks the evidence storage record as pending processing; the evidence storage record is updated after the blockchain evidence storage node returns to the write state.

[0222] Understandably, in actual operation scenarios, the payment institution interface returns a successful settlement result, the bank custody interface returns a successful fund transfer, and the insurance core interface returns a timeout result for premium addition. The S600 generates a compensation process result containing premium addition result query records and pending records. After reading this compensation process result, the workflow engine retrieves the order request data packet, settlement result, bank custody status, premium addition result, and process instance status from the same process instance. The workflow engine sequentially organizes the merchant identifier, user identifier, order amount, order time, settlement result, bank custody status, premium addition result, compensation process result, and process instance status, and generates a key transaction hash. Subsequently, the workflow engine writes the key transaction hash to the blockchain evidence storage node. After the blockchain evidence storage node returns a successful write status, the workflow engine generates an evidence storage record.

[0223] Furthermore, the evidence storage record consists of a key transaction hash, a process instance, a revenue sharing result, a bank custody status, a premium increase result, a compensation process result, a process instance status, and a write status. In the evidence storage record, the key transaction hash corresponds to the same transaction chain, the process instance corresponds to the consumption, revenue sharing, custody, and insurance status nodes, and the compensation process result corresponds to the Saga mode compensation processing result in S600. The workflow engine transmits the evidence storage record to S800. S800 performs Canal monitoring of MySQL Binlog and Elasticsearch synchronization processing based on the evidence storage record to obtain a query index.

[0224] In summary, the technical effects of this step are as follows: This step converts the compensation process results generated by S600 into key transaction hashes and evidence records. This step incorporates order request data packets, accounting results, bank custody status, premium increase results, compensation process results, and process instance status into the same hash processing procedure. The evidence records generated in this step are entered into S800 to support the generation of query indexes.

[0225] S800. Based on the stored evidence records, perform Canal monitoring of MySQL Binlog and Elasticsearch synchronization to obtain the query index.

[0226] This step follows the evidence storage record generated by S700. The data layer reads the evidence storage record and starts Canal to monitor the MySQL Binlog and Elasticsearch for synchronization. The evidence storage record is the input data for this step, and it includes key transaction hashes, process instances, revenue sharing results, bank custody status, premium addition results, compensation process results, process instance status, and write status. Canal is the monitoring component in the data layer. The MySQL Binlog is a MySQL binary log used to record changes to consumer order data, revenue sharing results, bank custody status, premium addition results, and compensation process results. Elasticsearch is the query system in the data layer. The query index is a query data structure generated based on the heterogeneous data synchronization results and is available for use by the user end, merchant end, business logic layer, and data analysis module.

[0227] Specifically, the data layer first reads the process instance and key transaction hash from the evidence storage record, and determines the consumer order data, billing result, bank custody status, premium increase result, and compensation process result that need to be monitored based on the process instance. The consumer order data corresponds to the order request data packet generated in S100. The billing result, the bank custody status, and the premium increase result correspond to the interface execution status generated in S500. The compensation process result corresponds to the compensation process result generated in S600. The key transaction hash corresponds to the evidence storage record generated in S700. The data layer establishes a correspondence between the above fields and writes the correspondence into the processing record.

[0228] Furthermore, the Canal monitors data changes in the MySQL Binlog corresponding to the process instance. These data changes include changes to consumer order data, billing results, bank custody status, premium increase results, and compensation process results. During monitoring, the Canal reads the change time, change fields, and change status from the MySQL Binlog and matches the change fields with the process instance. If the change field corresponds to the process instance, the Canal writes the change field into the heterogeneous data synchronization result. If the change field does not correspond to the process instance, the Canal does not write the heterogeneous data synchronization result and continues monitoring subsequent MySQL Binlog entries.

[0229] Furthermore, the heterogeneous data synchronization result consists of process instances, key transaction hashes, consumer order data, accounting results, bank custody status, premium addition results, compensation process results, and change times. The consumer order data includes merchant identifier, user identifier, order amount, order time, and payment channel. The accounting results include the success, failure, timeout, or processing status returned by the payment institution interface. The bank custody status includes the fund freeze status, fund transfer status, failure, timeout, or processing status. The premium addition result includes the success, failure, timeout, or processing status returned by the insurance core interface. The compensation process result includes refund records, unfreezing records, reverse transfer records, premium addition result query records, or pending records. Canal transmits the heterogeneous data synchronization result to Elasticsearch.

[0230] Furthermore, after receiving the heterogeneous data synchronization results, Elasticsearch performs field organization and query index generation. During field organization, Elasticsearch reads the process instance, key transaction hash, merchant identifier, user identifier, order amount, order time, payment channel, revenue sharing result, bank custody status, premium addition result, and compensation process result, and organizes these fields into query fields within the same query index. During query index generation, Elasticsearch establishes a main query field based on the process instance, a merchant-side query field based on the merchant identifier, a user-side query field based on the user identifier, and a notarized record query field based on the key transaction hash. The generated query index is written to the data layer and maintains a correspondence with the process instance, the key transaction hash, and the notarized record.

[0231] Furthermore, when Canal detects further changes to the revenue sharing result, bank custody status, premium increase result, or compensation process result of the same process instance, Canal generates a new heterogeneous data synchronization result. After reading the new heterogeneous data synchronization result, Elasticsearch searches the original query index and writes the changed revenue sharing result, bank custody status, premium increase result, or compensation process result into the query index. If the original query index does not exist, Elasticsearch generates a new query index based on the new heterogeneous data synchronization result. If the evidence record is marked as pending processing, Elasticsearch writes the pending processing record into the query index and retains the key transaction hash and the process instance.

[0232] Understandably, in a real-world scenario, after a process instance generates a record of evidence storage on the S700, the data layer reads the key transaction hash and process instance from that record. Subsequently, Canal monitors the MySQL Binlog for the corresponding consumption order data, accounting results, bank custody status, premium addition results, and compensation process results. If the premium addition result of the insurance core interface changes from "processing" to "successful," the MySQL Binlog records this change. Canal reads this change and generates a heterogeneous data synchronization result. After receiving the heterogeneous data synchronization result, Elasticsearch updates the query index corresponding to the process instance and writes the premium addition result, key transaction hash, and evidence storage record into the corresponding query fields.

[0233] Further, the data analysis module generates an operational report based on the query index. The operational report includes payment success rate, number of bank custody failures, number of premium payment failures, and number of compensation process steps. The data analysis module reads the accounting results from the query index to generate the payment success rate. The data analysis module reads the bank custody status from the query index to generate the number of bank custody failures. The data analysis module reads the premium payment results from the query index to generate the number of premium payment failures. The data analysis module reads the compensation process results from the query index to generate the number of compensation process steps. The data analysis module generates a risk level based on the operational report and transmits the risk level to the order routing engine. The order routing engine adjusts the order routing results according to the risk level and calls the risk level in subsequent steps (S200).

[0234] In one technical solution, the Canal immediately monitors the MySQL Binlog after the evidence record is generated and transmits the monitored data changes to Elasticsearch. In another technical solution, the Canal monitors the process instance status, and when the process instance status changes (e.g., changes in revenue sharing results, bank custody status, premium increase results, or compensation process results), it generates heterogeneous data synchronization results. In yet another technical solution, the Elasticsearch first generates a query index containing the process instance and key transaction hashes, and then supplements the consumer order data, revenue sharing results, bank custody status, premium increase results, and compensation process results based on the heterogeneous data synchronization results transmitted by the Canal.

[0235] Furthermore, the query index consists of process instances, key transaction hashes, consumer order data, billing results, bank custody status, premium increase results, compensation process results, evidence storage records, operational reports, and risk levels. This query index, as the output of this step, is sent back to the data layer for storage and is available for reading by the user end, merchant end, business logic layer, data analysis module, and order routing engine. The order routing engine reads the risk level in subsequent order routing result generation processing and uses it as input data to adjust the order routing results.

[0236] In summary, the technical effects of this step are as follows: This step converts the evidence storage records generated by S700 into a query index. This step uses Canal to monitor the MySQL Binlog, synchronizing consumer order data, billing results, bank custody status, premium payment results, and compensation process results to Elasticsearch. The query index generated in this step is then sent back to the data analysis module and the order routing engine, forming a closed loop between evidence storage records, query indexes, and risk levels.

[0237] Example 2: Figure 2 This diagram illustrates a structural block diagram of a multi-party collaborative consumer-based elderly care security service system according to an embodiment of the present invention. Figure 2 As shown, the structure may include:

[0238] The order access module 01 is used to acquire multi-protocol consumer order data from point-of-sale terminals, e-commerce platforms, or mobile applications, and perform protocol identification, merchant authentication, field mapping, and idempotency verification to obtain an order request data packet. Specifically, the order access module receives multi-protocol consumer order data submitted by point-of-sale terminals, e-commerce platforms, or mobile applications. The multi-protocol consumer order data includes a source identifier, request header information, message subject, service call information, merchant identifier, user identifier, order amount, order time, and payment channel. The order access module first reads the source identifier, request header information, message subject, and service call information, and performs protocol identification processing. Subsequently, the order access module reads the merchant identifier and payment channel, and performs merchant authentication processing. After successful merchant authentication, the order access module organizes the merchant identifier, user identifier, order amount, order time, and payment channel from different sources into a unified field. The order access module then performs idempotency verification processing based on the merchant identifier, user identifier, order amount, and order time. When the idempotency verification passes, the order access module forms an order request data packet and provides the order request data packet to the order routing module. If the idempotency check fails, the order access module records the pending status and saves the corresponding multi-protocol consumer order data.

[0239] The order routing module 02, connected to the order access module, is used to identify and process merchant type, online / offline status, and user policy information based on the order request data packet to obtain an order routing result. Specifically, the order routing module receives the order request data packet from the order access module and reads the merchant identifier, user identifier, order amount, and payment channel from the order request data packet. The order routing module searches for merchant access information based on the merchant identifier and performs merchant type identification processing to obtain the merchant type. The order routing module performs online / offline identification processing based on the source identifier and payment channel to obtain the consumption scenario. The order routing module reads the user policy information based on the user identifier and records the user identifier, policy status, and premium increase association information. After the merchant type, consumption scenario, and user policy information are all identified, the order routing module generates an order routing result. The order routing result includes the merchant type, consumption scenario, user policy information, merchant identifier, user identifier, order amount, order time, and payment channel, and is transmitted to the rule configuration module.

[0240] The rule configuration module 03, connected to the order routing module, is used to perform merchant rebate ratio, revenue sharing template reading, and revenue sharing amount calculation based on the order routing results to obtain the revenue sharing calculation results. Specifically, the rule configuration module receives the order routing results from the order routing module and reads the merchant type, consumption scenario, user policy information, merchant identifier, order amount, and payment channel from the order routing results. The rule configuration module reads the merchant rebate ratio based on the merchant identifier and merchant type, and reads the revenue sharing template based on the consumption scenario and payment channel. The revenue sharing template includes rules for generating real-time revenue sharing data from the payment institution interface, rules for generating fund freeze or transfer data from the bank custody interface, and rules for generating premium increase data from the insurance core interface. The rule configuration module performs revenue sharing amount calculation based on the order amount, merchant rebate ratio, revenue sharing template, and user policy information to generate the consumption incentive amount, and forms real-time revenue sharing data from the payment institution interface, fund freeze or transfer data from the bank custody interface, and premium increase data from the insurance core interface. The rule configuration module combines merchant identifier, user identifier, order amount, order time, payment channel, merchant rebate ratio, revenue sharing template, consumption incentive amount, and three types of interface data into a revenue sharing calculation result, and then transmits it to the workflow module.

[0241] Workflow module 04, connected to the rule configuration module, is used to create process instances and set consumption, revenue sharing, custody, and insurance status nodes based on the revenue sharing calculation results, thereby obtaining the process instance status. Specifically, the workflow module receives the revenue sharing calculation results from the rule configuration module and reads the merchant identifier, user identifier, order amount, order time, payment channel, consumption incentive amount, and three types of interface data. The workflow module creates a process instance based on the same revenue sharing calculation result. The process instance sets consumption status nodes, revenue sharing status nodes, custody status nodes, and insurance status nodes. The consumption status node records the order request data packet and order amount. The revenue sharing status node records the consumption incentive amount and real-time revenue sharing data from the payment institution interface. The custody status node records the fund freeze or transfer data from the bank custody interface. The insurance status node records the premium addition data from the insurance core interface. The workflow module writes the node sequence records in the order of consumption status nodes, revenue sharing status nodes, custody status nodes, and insurance status nodes, and generates the process instance status. The process instance status is then transmitted to the external interface module.

[0242] External interface module 05, connected to the workflow module, is used to perform real-time settlement processing for the payment institution interface, fund freezing or transfer for the bank custody interface, and policy query and premium addition processing for the insurance core interface based on the process instance status, obtaining the interface execution status. Specifically, the external interface module receives the process instance status from the workflow module and reads the real-time settlement data of the payment institution interface from the settlement status node. The external interface module calls the payment institution interface to perform real-time settlement processing and obtains the settlement result. When the settlement result is successful, the external interface module reads the fund freezing or transfer data of the bank custody interface from the custody status node and calls the bank custody interface to perform fund freezing or transfer processing, obtaining the bank custody status. When the bank custody status indicates successful fund freezing or successful fund transfer, the external interface module reads the user policy information and premium addition data from the insurance status node and calls the insurance core interface to perform policy query and premium addition processing, obtaining the policy query result and premium addition result. The external interface module will combine the accounting results, bank custody status, policy query results, and premium increase results into an interface execution status and transmit it to the compensation processing module.

[0243] The compensation processing module 06, connected to the external interface module, is used to determine and compensate for failures, timeouts, or overdue processing based on the interface execution status, thereby obtaining the compensation process result. Specifically, the compensation processing module receives the interface execution status from the external interface module and reads the process instance, accounting result, bank custody status, policy query result, premium addition result, interface return time, and the correspondence between status nodes. The compensation processing module first determines the accounting result. If the accounting result is a failure, timeout, or overdue processing, the compensation processing module records the accounting status node as pending processing. If the accounting result is successful and the bank custody status is a failure, timeout, or overdue processing, the compensation processing module performs a refund or marks it as pending processing. If the bank custody status is a successful fund freeze and the policy query result is a failure, timeout, or overdue processing, the compensation processing module performs an unfreezing process. When the bank custody status indicates successful fund transfer but the premium increase result is failed, timed out, or overdue during processing, the compensation processing module performs a reverse transfer, premium increase result query, or marks it as pending. The compensation processing module combines the refund record, unfreezing record, reverse transfer record, premium increase result query record, or pending record into a compensation process result and transmits it to the evidence processing module.

[0244] The evidence storage processing module 07, connected to the compensation processing module, is used to generate key transaction hashes and write data to the blockchain evidence storage node based on the compensation process results, obtaining evidence storage records. Specifically, the evidence storage processing module receives the compensation process results from the compensation processing module and reads the order request data packet, settlement result, bank custody status, premium addition result, and process instance status according to the process instance. The evidence storage processing module organizes the fields of merchant identifier, user identifier, order amount, order time, settlement result, bank custody status, premium addition result, compensation process results, and process instance status. After the field organization is completed, the evidence storage processing module performs key transaction hash generation to obtain the key transaction hash. The evidence storage processing module sends the key transaction hash, process instance, and compensation process results to the blockchain evidence storage node. The blockchain evidence storage node performs write processing and returns the write status. When the write status is successful, the evidence storage processing module generates an evidence storage record. When the write status is failed, timed out, or in progress, the evidence storage processing module marks the evidence storage record as pending processing. The evidence storage record is then passed to the query synchronization module.

[0245] The query synchronization module 08, connected to the evidence storage processing module, is used for binary log monitoring and query synchronization processing based on the evidence storage records to obtain a query index. Specifically, the query synchronization module receives evidence storage records from the evidence storage processing module and reads key transaction hashes, process instances, revenue sharing results, bank custody status, premium addition results, compensation process results, and write status. The query synchronization module monitors binary logs based on the process instances, reading changes to consumer order data, revenue sharing results, bank custody status, premium addition results, and compensation process results. The query synchronization module establishes a correspondence between the changes and the process instances, key transaction hashes, and evidence storage records, forming a heterogeneous data synchronization result. The query synchronization module transmits the heterogeneous data synchronization result to the query system and performs field organization. The organized fields include process instances, key transaction hashes, merchant identifiers, user identifiers, order amounts, order times, payment channels, revenue sharing results, bank custody status, premium addition results, and compensation process results. After the fields are organized, the query synchronization module generates a query index and provides the query index to the business logic layer, data analysis module, and order routing module for use.

Claims

1. A multi-party collaborative method for providing consumer-based elderly care security services, characterized in that: include: S100: Obtain multi-protocol consumer order data generated by POS machines, e-commerce platforms, or mobile apps, and sequentially perform HTTP / HTTPS, MQ, and RPC protocol identification, merchant authentication, field mapping, and idempotency verification to generate an order request data packet; S200: Based on the order request data packet, complete the identification of merchant type, online and offline scenarios and user policy information, and output the order routing result; S300. Based on the order routing results, retrieve the merchant rebate ratio and revenue sharing template, complete the revenue sharing amount calculation, and obtain the revenue sharing calculation result; S400. Based on the revenue sharing calculation results, create a process instance and configure the corresponding status nodes for consumption, revenue sharing, custody, and insurance, and determine the status of the process instance. S500. Based on the status of the process instance, call the payment institution interface for real-time settlement, the bank custody interface to complete the freezing or transfer of funds, and the insurance core interface to realize policy inquiry and premium addition, and provide feedback on the interface execution status. S600. For the execution status of the interface, identify failure, timeout, and expiration exceptions, and perform compensation processing in Saga mode to generate compensation process results. S700. Based on the results of the compensation process, generate a key transaction hash and write it into the blockchain evidence storage node to form an evidence storage record. S800: Based on the stored evidence records, use Canal to monitor MySQL Binlog logs and synchronize them to Elasticsearch to build a business query index.

2. The method according to claim 1, characterized in that, The process of performing HTTP / HTTPS, MQ, and RPC protocol identification, merchant authentication, field mapping, and idempotency validation includes: The protocol identification process includes: the multi-protocol gateway reads the source identifier, request header information, message topic and service call information, identifies the HTTP, HTTPS, MQ or RPC protocol type, and writes the protocol type into the processing status of the multi-protocol consumption order data; The merchant authentication process includes: the multi-protocol gateway performs merchant identifier matching, source identifier matching, and payment channel matching based on the merchant identifier, source identifier matching, and payment channel matching, and writes the merchant authentication result into the processing status after all matching passes. The field mapping process includes: the multi-protocol gateway organizes the offline order fields from the POS machine, the online order fields from the e-commerce platform, and the user order fields from the mobile APP into unified fields such as merchant identifier, user identifier, order amount, order time, and payment channel to form intermediate data; The idempotency verification process includes: the multi-protocol gateway performs duplicate identification on the intermediate data based on the same merchant identifier, the same user identifier, the same order amount, and the same order time; when no duplicate records are found, it generates an idempotency verification result in a pass state; and encapsulates the merchant identifier, user identifier, order amount, order time, payment channel, protocol type, merchant authentication result, and idempotency verification result into an order request data packet.

3. The method according to claim 2, characterized in that, The process of identifying and processing merchant types, online and offline scenarios, and user policy information includes: The merchant type identification process includes: the order routing engine reads the merchant authentication result and idempotency verification result in the order request data packet, and when both are in a passed state, reads the merchant identifier and payment channel, matches them with the merchant access information stored in the business logic layer, and identifies the merchant type as online merchant, offline merchant, or merchant with both online and offline access records. The online and offline scenario identification and processing includes: the order routing engine identifies the offline consumption scenario based on the protocol type, payment channel and the source of the order request data packet. If the data packet originates from a POS machine and the payment channel corresponds to an offline payment channel, it is identified as an offline consumption scenario. If the data packet originates from an e-commerce platform or mobile APP and the payment channel corresponds to an online payment channel, it is identified as an online consumption scenario. The user policy information identification and processing includes: the order routing engine reads user policy information from Redis and L1 local cache first, based on the user identifier; if the read is not found, it initiates a policy query to obtain user policy information containing user identifier, policy status and premium addition association information. The order routing engine combines the merchant type, consumption scenario, user policy information, merchant identifier, user identifier, order amount, order time, and payment channel to form the order routing result.

4. The method according to claim 3, characterized in that, The process of retrieving merchant rebate ratios and revenue sharing templates and completing revenue sharing calculations includes: The process of retrieving merchant rebate ratios and revenue sharing templates includes: the rule configuration center reading the merchant identifier and merchant type from the order routing results, searching for the corresponding merchant rebate ratio in the hot merchant configuration; then reading the consumption scenario and payment channel, and searching for the revenue sharing template corresponding to the consumption scenario and payment channel; the revenue sharing template includes the real-time revenue sharing data generation rules of the payment institution interface, the fund freezing or transfer data generation rules of the bank custody interface, and the premium increase data generation rules of the insurance core interface. The revenue sharing calculation process includes: the rule configuration center obtains the consumption incentive amount based on the order amount and the merchant rebate ratio, and then organizes the consumption incentive amount into real-time revenue sharing data of the payment institution interface, fund freezing or transfer data of the bank custody interface, and premium addition data of the insurance core interface according to the revenue sharing template; the revenue sharing calculation result includes merchant identifier, user identifier, order amount, order time, payment channel, merchant rebate ratio, revenue sharing template, consumption incentive amount, real-time revenue sharing data, fund freezing or transfer data, and premium addition data.

5. The method according to claim 4, characterized in that, The process of creating a workflow instance and configuring the corresponding status node processing for consumption, revenue sharing, custody, and insurance includes: The creation process instance includes: the workflow engine reads the merchant identifier, user identifier, order amount, order time, and payment channel from the revenue sharing calculation result as basic fields, and then reads the consumption incentive amount, real-time revenue sharing data, fund freezing or transfer data, and premium addition data as processing data. When all of these exist, a process instance is created, and a corresponding relationship is established with the order request data packet, order routing result, and revenue sharing calculation result. The configuration status nodes include: the workflow engine sets consumption status nodes, revenue sharing status nodes, custody status nodes, and insurance status nodes in the process instance; the consumption status node records merchant identifier, user identifier, order amount, order time, and payment channel; the revenue sharing status node records consumption incentive amount and real-time revenue sharing data; the custody status node records fund freezing or transfer data; and the insurance status node records premium increase data. The status nodes are written into the node sequence record in the order of consumption status node, accounting status node, custody status node, and insurance status node, and the status transition result of the previous status node is used as the processing data for the subsequent status node; the workflow engine generates a process instance status that includes the process instance, each status node, node sequence record, and status transition result.

6. The method according to claim 5, characterized in that, The process of calling payment institution interfaces for real-time settlement, bank custody interfaces for freezing or transferring funds, and insurance core interfaces for policy inquiries and premium increases includes: The process of calling the payment institution interface includes: the workflow engine reading the splitting status node in the process instance status, extracting real-time splitting data and calling the payment institution interface to receive the splitting result, which includes the status of success, failure, timeout or processing. The process of calling the bank custody interface includes: when the settlement result is successful, the workflow engine reads the fund freezing or transfer data in the custody status node and calls the bank custody interface to receive the bank custody status including the status of successful fund freezing, successful fund transfer, failure, timeout or processing. The process of calling the insurance core interface includes: when the bank custody status is successful fund freezing or successful fund transfer, the workflow engine reads the premium addition data and user policy information in the insurance status node, calls the insurance core interface to perform policy query and premium addition, and receives premium addition results including success, failure, timeout or processing status. The workflow engine combines the revenue sharing results, bank custody status, and premium increase results into the interface execution status.

7. The method according to claim 6, characterized in that, The process of identifying failures, timeouts, and expirations and performing compensation processing using the Saga pattern includes: The anomaly identification includes: the workflow engine reads the revenue sharing result in the interface execution status; if it is a failure, timeout, or processing overdue, the revenue sharing status node is recorded as pending; if the revenue sharing result is successful, it continues to read the bank custody status; if the bank custody status is a failure, timeout, or processing overdue, Saga compensation is initiated; if the bank custody status is a successful fund freeze, the policy query result is read; if the policy query result is a failure, timeout, or processing overdue, the unfreezing process is executed; if the bank custody status is a successful fund transfer, the premium addition result is read; if the premium addition result is a failure, timeout, or processing overdue, a reverse transfer or premium addition result query is executed. The Saga mode compensation process includes: when the settlement result is successful but the bank custody status is failed, timed out, or overdue during processing, the workflow engine processes the refund or marks it as pending based on the settlement result recorded in the settlement status node; when the funds are successfully frozen but the policy query result is abnormal, the workflow engine performs the unfreezing process; when the funds are successfully transferred but the premium increase result is abnormal, the workflow engine performs the reverse transfer, premium increase result query, or marks it as pending. The compensation process results include process instance, account splitting results, bank custody status, policy inquiry results, premium increase results, refund records, unfreezing records, reverse transfer records, premium increase result inquiry records, pending records, and compensation processing time.

8. The method according to claim 7, characterized in that, The process of generating key transaction hashes and writing them to blockchain storage nodes includes: The generation of the key transaction hash includes: the workflow engine reads the process instance in the compensation process result, retrieves the corresponding order request data packet, revenue sharing calculation result and process instance status, extracts the merchant identifier, user identifier, order amount, order time, revenue sharing result, bank custody status, premium addition result, compensation process result and process instance status as necessary fields, arranges them in the order of order request data packet, revenue sharing result, bank custody status, premium addition result, compensation process result and process instance status, and performs hash processing on the arranged fields to obtain the key transaction hash; The process of writing to the blockchain evidence storage node includes: the workflow engine encapsulating key transaction hashes, process instances, compensation process results, and process instance status into evidence storage writing data and sending it to the blockchain evidence storage node; after receiving the data, the blockchain evidence storage node performs key transaction hash writing, process instance writing, and compensation process result writing, and returns the writing status; the workflow engine generates evidence storage records based on the writing status.

9. The method according to claim 8, characterized in that, The process by which Canal listens to MySQL Binlog logs and synchronizes them to Elasticsearch includes: The Canal monitoring of the MySQL Binlog includes: the data layer reading process instances and key transaction hashes from the evidence storage records to determine the consumer order data, billing results, bank custody status, premium addition results, and compensation process results that need to be monitored; Canal monitoring data changes corresponding to the process instances in the MySQL Binlog, matching the changed fields with the process instances, and generating heterogeneous data synchronization results containing the process instance, key transaction hashes, consumer order data, billing results, bank custody status, premium addition results, compensation process results, and change time; The synchronization to Elasticsearch includes: after receiving the heterogeneous data synchronization results, Elasticsearch organizes the fields, reads the process instance, key transaction hash, merchant identifier, user identifier, order amount, order time, payment channel, revenue sharing result, bank custody status, premium addition result, and compensation process result, and organizes them into query fields in the same query index; it establishes the main query field based on the process instance, the merchant-side query field based on the merchant identifier, the user-side query field based on the user identifier, and the evidence record query field based on the key transaction hash, and generates a business query index.

10. A multi-party collaborative consumer-based elderly care security service system, characterized in that, include: The system comprises an order access module, an order routing module, a rule configuration module, a workflow module, an external interface module, a compensation processing module, an evidence storage processing module, and a query synchronization module; these modules are connected in sequence to implement the method described in any one of claims 1-9.

Images