A rule-based method for processing license and certificate usage on-chain

Abstract

The present invention provides a rule-based method for processing the use of certificates and licenses on the chain. By defining the business rules for the use of certificates and licenses according to different business scenarios in advance, the interface address, parameter name, parameter type, and parameter constraint information used in the business scenarios are customized. Each business scenario is bound to a customized processing rule logic, and the logical processing is configured and orchestrated by the rule engine. The application of this technical solution can improve the flexible customization capabilities of the business and reduce the coupling between the system and the business system.

Description

Technical Field

[0001] The present invention relates to the technical field of electronic certificate processing, and in particular to a rule-based certificate and use certificate chain processing method. Background Art

[0002] The traditional lifecycle of an electronic certificate includes production, use, and expiration. After production, records are saved in a record table based on the lifecycle and uploaded asynchronously to the blockchain platform. Due to the concurrency limitations of blockchain uploads, asynchronous queues are used for uploading. This technology uses a data service device to store asynchronous information and uploads the certificate usage record to the blockchain using Kafka consumption and multi-threading technology. After successful upload, the returned transaction number is bound to the certificate usage record.

[0003] The existing description model is cumbersome for business expansion. It requires categorizing business scenarios and developing license usage and on-chain record keeping functions based on those scenarios. Data persistence and the ability to support license on-chain business operations under high concurrency must also be ensured. Long call chains create a lack of transparency during asynchronous processing, making it impossible to effectively troubleshoot issues when asynchronous on-chain exceptions occur, and it's impossible to dynamically add processing logic to each link. Summary of the Invention

[0004] In view of this, the purpose of the present invention is to provide a rule-based method for processing the chain of certificates and licenses, so as to improve the flexible customization capabilities of the business and reduce the coupling between the system and the business system.

[0005] To achieve the above objectives, the present invention adopts the following technical solution: a rule-based method for processing license and certificate usage on a blockchain, comprising the following steps:

[0006] Step 1: Use the online browser to visualize the rule orchestration engine. The engine is divided into the component area, view display area, and component property area. Select the HTTP / KAFKA component as the starting point and drag it to the view display area. The execution order of the components is connected by lines. If a component node has only one output line, it is serial processing. If it has multiple output lines, it is parallel processing. Click the component in the view to edit its properties. Single line / multiple lines determine whether the component orchestration is executed serially or in parallel.

[0007] Step 2: The results of the rule engine are stored in the rule expression and function script in JSON format;

[0008] Step 3: Built-in default components are divided into general components, functional components, blockchain components, storage components, and network components. These components are executed serially or in parallel according to regular expressions. Serial execution is arranged using the THEN keyword. For example, the THEN(a,b,c) expression first executes component a, then components b and c. Parallel execution is encoded using the WHEN keyword.

[0009] Step 4: Define different e-certificate usage scenarios based on the item number. Each scenario will select a rule pre-defined by the rule engine and store it in the business scenario table with a 1:1 relationship.

[0010] Step 5: The card business system requests the card data to be uploaded to the blockchain based on the scenario ID. The reqId and request time of this request are generated based on the scenario parameter rule constraints and submitted to the rule engine together with the scenario ID. Each business scenario defines multiple upload parameters.

[0011] Step 6: The rule engine reads the rule expression from the cache. The rule executor executes the expression based on the rule identifier chain_id, interpreting the THEN and WHEN keywords for serial or parallel execution. These components are built into the system. If asynchronous chaining is required, the Kafka component can be selected.

[0012] Step 7: The synchronously executed rules will be fed back to the third-party business system in real time, and the results of asynchronous on-chain will be sent to the third-party business system through the HTTP request component in the network component.

[0013] In a preferred embodiment, in step 1, the data source for defining the rule is an HTTP interface or KAFKA message data.

[0014] In a preferred embodiment, in step 3, the general component serves as the data source, and the functional components include a debugging component, a function component, a custom script component, and an abnormal alarm component.

[0015] In a preferred embodiment, in step 5, the parameter rule consists of parameter name, parameter type, parameter length, whether it is required, and default value.

[0016] Compared with the existing technology, the present invention has the following beneficial effects: in the process of executing the chain of license use, the rule engine can be used to configure the execution logic through different business scenarios. The rule definition engine based on the business scenario of the present invention can achieve synchronous / asynchronous chain-up while monitoring the entire chain-up process and saving the process and results to the database through built-in components. It can ensure performance and flexible expansion even in high-throughput and complex business situations, greatly improving the expansion capability and flexibility. BRIEF DESCRIPTION OF THE DRAWINGS

[0017] Figure 1Schematic diagram of a preferred embodiment of the present invention. DETAILED DESCRIPTION

[0018] The present invention will be further described below with reference to the accompanying drawings and embodiments.

[0019] It should be noted that the following detailed descriptions are illustrative and intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as commonly understood by those skilled in the art to which the present application belongs.

[0020] It should be noted that the terms used herein are only for describing specific embodiments and are not intended to limit the exemplary embodiments according to the present application; as used herein, unless the context clearly indicates otherwise, the singular form is also intended to include the plural form, and it should be understood that when the terms "comprise" and / or "include" are used in this specification, they indicate the presence of features, steps, operations, devices, components and / or their combinations.

[0021] A rule-based method for processing licenses and certificates on the chain, refer to Figure 1 By defining the business rules for the use of certificates and licenses in advance according to different business scenarios, and customizing the interface address, parameter name, parameter type, and parameter constraint information used in the business scenarios, each business scenario is bound to a custom processing rule logic. The logical processing is configured and orchestrated by the rule engine. The chain-up method is flexibly customized according to different business scenarios with custom data processing functions. The rule engine includes general components (HTTP listening, KAFKA listening), functional components (DEBUG components, function components, script components, abnormal alarms), network components (HTTP requests, KAFKA sending), storage components (MySql storage, Redis storage, Elasticsearch storage), and blockchain components (block chaining, block verification). The rule engine defines the data source of the certificate-using business scenario based on the HTTP listening / KAFKA listening in the general components. When using the certificate, each business scenario will generate three parameters: scenario ID, request ReqId, and request time as the lifecycle information of the certificate chain, which improves the troubleshooting ability when exception processing occurs. The rule engine can use synchronous / asynchronous methods for data on-chain according to different business scenarios, and can also execute different components in parallel according to business needs. After successful on-chain storage, the data can be stored in MySql through orchestration, and can also be filtered through custom functions and then stored in Elasticsearch. This greatly improves the flexible customization capabilities of the business and reduces the coupling between the system and the business system.

[0022] Specifically, the following steps are included:

[0023] Step 1: Use the online browser to visualize the rule orchestration engine. The engine is divided into the component area, view display area, and component attribute area. Select the HTTP / KAFKA component as the starting point and drag it to the view display area. The execution order of the components is connected by lines. When a component node has only one output line, it is serial processing. If there are multiple output lines, it is parallel processing. The data source of the defined rule is the HTTP interface or KAFKA message data. Click the component in the view to edit its attributes. Single line / multiple lines determine whether the component orchestration is executed serially or in parallel.

[0024] Step 2: The results of the rule engine compilation are stored in the rule expression and function script in JSON format.

[0025] Step 3: Built-in default components are divided into general components (data sources), functional components (debugging components, function components, custom script components, and abnormal alarm components), blockchain components, storage components, and network components. These components can be executed serially or in parallel according to regular expressions. Serial execution is orchestrated using the THEN keyword, such as the THEN(a,b,c) expression, which executes component a first, and then components b and c. Parallel execution is encoded using the WHEN keyword, such as the WHEN(a,b,c) expression, which executes components a, b, and c simultaneously.

[0026] Step 4: Define different e-certificate usage scenarios based on the item number. Each scenario will select a rule pre-defined by the rule engine and store it in the business scenario table with a 1:1 relationship.

[0027] Step 5: The certificate business system requests the certificate data to be uploaded to the chain based on the scenario ID. The reqId and request time of this request are generated through the parameter rule constraints of the scenario and submitted to the rule engine together with the scenario ID. The parameter rules consist of parameter name, parameter type, parameter length, whether it is required, and default value. Each business scenario can define multiple chain parameters.

[0028] Step 6: The rule engine reads the rule expression from the cache. The rule executor executes the expression based on the rule identifier chain_id, interpreting the THEN and WHEN keywords for serial or parallel execution. These components are built into the system. If asynchronous chaining is required, the Kafka component can be selected.

[0029] Step 7: The synchronously executed rules will be fed back to the third-party business system in real time, and the results of asynchronous on-chain will be sent to the third-party business system through the HTTP request component in the network component.

[0030] The purpose of this invention is to provide a set of functions for customizing the on-chain recording of license usage according to business scenarios. On this basis, the rule engine can flexibly define and monitor the entire life cycle of data on-chain. It can be highly customized for synchronous / asynchronous on-chain, data storage methods, network notifications, and business debugging. Main features: 1. The entire life cycle of the certificate record on the chain is managed by ReqId.

[0031] 2. Supports multiple built-in related rule engine execution components, which is conducive to flexible expansion and monitoring of the entire process.

[0032] 3. Prevent repeated submission of the same Req request and generation of redundant business data.

[0033] 4. Flexible and customizable business scenarios, defining on-chain data constraints for different business scenarios.

[0034] 5. Use serial / parallel methods to execute built-in components through regular expressions.

[0035] 6. Supports flexible definition of synchronous / asynchronous methods, which can be applied to different scenarios of certificate record on-chain.

Claims

1. A rule-based method for processing licenses and certificates on-chain, characterized by The following steps are involved: Step 1: Use the online browser to visualize the rule orchestration engine. The engine is divided into the component area, view display area, and component property area. Select the HTTP / KAFKA component as the starting point and drag it to the view display area. The execution order of the components is connected by lines. If a component node has only one output line, it is serial processing. If it has multiple output lines, it is parallel processing. Click the component in the view to edit its properties. Single line / multiple lines determine whether the component orchestration is executed serially or in parallel. Step 2: The results of the rule engine are stored in the rule expression and function script in JSON format; Step 3: The built-in default components are divided into general components, functional components, blockchain components, storage components, and network components. These components are executed serially or in parallel according to regular expressions. Serial execution is orchestrated using the THEN keyword. The serial THEN (a, b, c) expression first executes component a, then components b and c. Parallel execution is encoded using the WHEN keyword. Step 4: Define different e-certificate usage scenarios based on the item number. Each scenario will select a rule pre-defined by the rule engine and store it in the business scenario table with a 1:1 relationship. Step 5: The card business system requests the card data to be uploaded to the blockchain based on the scenario ID. The reqId and request time of this request are generated based on the scenario parameter rule constraints and submitted to the rule engine together with the scenario ID. Each business scenario defines multiple upload parameters. Step 6: The rule engine reads the rule expression from the cache. The rule executor executes the expression based on the rule identifier chain_id, interpreting the THEN and WHEN keywords for serial or parallel execution. These components are built into the system. If asynchronous chaining is required, the Kafka component can be selected. Step 7: The synchronously executed rules will be fed back to the third-party business system in real time, and the asynchronous on-chain results will be sent to the third-party business system via the HTTP request component in the network component; In step 1, the data source of the defined rule is HTTP interface or KAFKA message data; In step 3, the general component serves as the data source, and the functional components include the debugging component, the function component, the custom script component, and the abnormal alarm component; In step 5, the parameter rule consists of parameter name, parameter type, parameter length, whether it is required, and default value.

Images