Business strategy configuration and execution methods, devices, equipment and media

Abstract

This invention relates to the field of R&D management technology, and discloses a method, apparatus, device, and medium for configuring and executing business strategies. The method includes: parsing strategy change messages to generate a strategy model and establishing an association between strategy codes and strategy execution scripts; obtaining interface rendering data from the strategy model based on product identifiers; generating strategy filtering conditions based on business scenario parameters and storing them in association with the strategy codes; matching current scenario information to filter a list of strategies to be executed; calling the strategy execution script to process the data to be processed and obtain strategy execution results; and assembling response information based on the strategy execution results and returning it. This invention can be applied to business scenarios such as financial property insurance. By decoupling strategy parsing and strategy execution, and combining a unified strategy model and a scenario-based filtering mechanism, it enables dynamic configuration and on-demand execution of verification rules, shortens the rule adjustment cycle, reduces system modification risks, and improves rule reusability.

Description

Technical Field

[0001] This invention relates to the field of R&D management technology, and in particular to a business strategy configuration and execution method, apparatus, equipment and medium. Background Technology

[0002] In financial and insurance business, electronic contracts typically require rigorous verification of insurance information before issuance to determine whether the data provided by the insured meets product underwriting requirements and regulatory reporting requirements. Factors such as document validity, completeness of geographical information, and the legality of the insurance source directly affect whether a contract can be generated and subsequent compliance audits. Therefore, upon receiving an insurance request, the business system must execute multiple rule checks to identify potential risks and block ineligible requests.

[0003] In existing technologies, most of these validation rules are embedded in the backend business program, with the rule logic highly coupled with the business process and product processing code. When regulatory policies, product rules, or risk control requirements are adjusted, such as adding mandatory field validation or adding validation of relationships between fields, it is often necessary to modify the program code. This requires going through a complete software iteration process, including requirements analysis, development, testing, and deployment, resulting in long rule adjustment cycles and slow response times.

[0004] Furthermore, existing implementations typically lack unified rule management and the ability to filter rules based on business scenarios. The same or similar verification logic is repeatedly implemented across different product systems, making rule reuse and unified management difficult. When receiving an insurance application, the system often executes all relevant verifications one by one according to a fixed process, failing to dynamically determine the set of rules to be executed based on product attributes or business scenarios. This increases system complexity and raises potential production risks due to frequent modifications. Summary of the Invention

[0005] The main objective of this invention is to provide a business strategy configuration and execution method, apparatus, device, and storage medium, which aims to solve the technical problem in the prior art where the deep coupling between verification rules and business program logic leads to rule changes having to rely on a complete software iteration process, making it impossible to achieve dynamic configuration and on-demand execution of rules according to product and business scenarios.

[0006] To achieve the above objectives, the present invention provides a business strategy configuration and execution method, comprising: Upon receiving a policy change message, the system calls a stored policy parsing script to parse the policy change message, generates a policy model containing policy codes and policy configuration attributes, and stores the policy model in association with the product identifier. The policy code is associated with a pre-stored policy execution script. In response to a configuration request for a product identifier, the corresponding strategy model is obtained based on the product identifier, and interface rendering data is generated based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface. Receive business scenario parameters submitted through the policy configuration interface, generate policy filtering conditions based on the business scenario parameters, and associate and store the policy filtering conditions with the corresponding policy codes. Receive a business execution request, extract current scenario information from the business execution request, match the policy filtering conditions according to the current scenario information, and filter out a list of execution policies containing at least one target policy code; Traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request to the target strategy execution script for execution, and obtain the strategy execution result; The response information is assembled and returned based on the execution result of the strategy.

[0007] Furthermore, to achieve the above objectives, the present invention provides a business strategy configuration and execution apparatus, comprising: The strategy modeling module is used to receive strategy change messages, call the stored strategy parsing script to parse the strategy change messages, generate a strategy model containing strategy codes and strategy configuration attributes, and store the strategy model in association with the product identifier. The strategy code is associated with a pre-stored strategy execution script. The interface rendering data generation module is used to respond to the configuration request for the product identifier, obtain the corresponding strategy model according to the product identifier, and generate interface rendering data based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface. The strategy filtering construction module is used to receive business scenario parameters submitted through the strategy configuration interface, generate strategy filtering conditions according to the business scenario parameters, and associate and store the strategy filtering conditions with the corresponding strategy codes. The strategy filtering module is used to receive a business execution request, extract current scenario information from the business execution request, match the strategy filtering conditions according to the current scenario information, and filter out a list of strategies to be executed that contain at least one target strategy code. The strategy execution scheduling module is used to traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request to the target strategy execution script for execution, and obtain the strategy execution result. The result encapsulation module is used to assemble response information based on the strategy execution result and return it.

[0008] Furthermore, to achieve the above objectives, the present invention also provides a computer device, the computer device including a memory, a processor, and a business strategy configuration and execution program stored in the memory and executable on the processor, wherein when the business strategy configuration and execution program is executed by the processor, it implements the steps of the business strategy configuration and execution method as described above.

[0009] Furthermore, to achieve the above objectives, the present invention also provides a computer-readable storage medium storing a business strategy configuration and execution program, wherein the business strategy configuration and execution program, when executed by a processor, implements the steps of the business strategy configuration and execution method as described above.

[0010] Beneficial Effects: This invention relates to the field of R&D management technology, and discloses a business strategy configuration and execution method, apparatus, equipment, and medium, including: parsing strategy change messages to generate a strategy model containing strategy codes and strategy configuration attributes, and establishing an association between strategy codes and strategy execution scripts; obtaining interface rendering data based on the strategy model according to the product identifier; receiving business scenario parameters to generate strategy filtering conditions and storing them in association with the strategy codes; extracting current scenario information from business execution requests to match the strategy filtering conditions to obtain a list of strategies to be executed; calling the strategy execution script according to the target strategy code to process the data to be processed and obtain the strategy execution result; assembling response information based on the strategy execution result and returning it. This invention can be applied to business scenarios such as financial property insurance. By decoupling strategy parsing and strategy execution, and combining a unified strategy model and a scenario-based filtering mechanism, it enables dynamic configuration and on-demand execution of verification rules, shortens the rule adjustment cycle, reduces the risk of system modification, and improves rule reusability. Attached Figure Description

[0011] The present invention will be further described below with reference to the accompanying drawings and embodiments. In the accompanying drawings: Figure 1 This is a schematic diagram of an application environment for a business strategy configuration and execution method according to an embodiment of the present invention; Figure 2 This is a flowchart illustrating an embodiment of the business strategy configuration and execution method of the present invention; Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the business strategy configuration and execution device of the present invention; Figure 4 This is a schematic diagram of the structure of a computer device according to an embodiment of the present invention; Figure 5 This is another structural schematic diagram of a computer device according to one embodiment of the present invention. Detailed Implementation

[0012] It should be understood that the specific embodiments described herein are for illustrative purposes only and are not intended to limit the scope of the invention.

[0013] The business strategy configuration and execution method provided in this embodiment of the invention can be applied to, for example... Figure 1 In this application environment, the client communicates with the server via a network. The server can receive and parse policy change messages from the client to generate a policy model containing policy codes and policy configuration attributes, and establish an association between the policy codes and policy execution scripts; obtain the policy model based on the product identifier to generate interface rendering data; receive business scenario parameters to generate policy filtering conditions and store them in association with the policy codes; extract the current scenario information from the business execution request, match the policy filtering conditions to obtain a list of policies to be executed; call the policy execution script based on the target policy code to process the data to be processed and obtain the policy execution result; assemble response information based on the policy execution result and return it. This invention can be applied to business scenarios such as financial property insurance. By decoupling policy parsing and policy execution, and combining a unified policy model and a scenario-based filtering mechanism, it achieves dynamic configuration and on-demand execution of verification rules, shortens the rule adjustment cycle, reduces the risk of system modification, and improves rule reuse capabilities. The client can be, but is not limited to, various personal computers, laptops, smartphones, tablets, and portable wearable devices. The server can be implemented using a separate server or a server cluster composed of multiple servers. The following is a detailed description of the invention through specific embodiments.

[0014] Please see Figure 2 , Figure 2 This is a flowchart illustrating an embodiment of the business strategy configuration and execution method provided by the present invention. It should be noted that although a logical order is shown in the flowchart, in some cases, the steps shown or described may be executed in a different order than that shown here.

[0015] like Figure 2 As shown, the business strategy configuration and execution method proposed in this invention includes the following steps: S10, Receive a policy change message, call the stored policy parsing script to parse the policy change message, generate a policy model containing policy code and policy configuration attributes, and store the policy model in association with the product identifier. The policy code is associated with a pre-stored policy execution script. In this embodiment, receiving policy change messages involves listening to and reading structured rule data from the rule management or product management end. This type of data typically includes information such as field constraint relationships, validation logic, and field display attributes. In financial insurance business, this type of rule data often carries regulatory reporting constraints, insurance information integrity requirements, and restrictions on logical relationships between fields. The stored policy parsing script is invoked for parsing, which involves identifying and decomposing the field structure and logical expression in the rule data through a script interpretation mechanism, transforming the original rule expression into a unified data description form. The policy parsing script is responsible for converting rule language into a unified expression model, enabling rule descriptions from different sources and in different formats to form a consistent data structure. During the parsing process, the unique identifier in the rule is extracted as a policy code, and the field types, field interaction forms, and field constraint relationships involved in the rule are extracted as policy configuration attributes. The policy code is used to uniquely identify the rule entity, and the policy configuration attributes are used to describe the behavioral characteristics of the rule in interface presentation and subsequent filtering. The parsed policy code and policy configuration attributes are encapsulated into a policy model. This policy model serves as a unified carrier for rule expression and is associated with the product identifier, enabling different products to reference different rule sets or share rule sets. A correspondence is established between the policy code and the pre-stored policy execution script. Through encoding, a searchable mapping is formed in the script storage area, creating a decoupled structure between rule expression and rule execution. Under this structure, changes to the rule content do not depend on modifications to the business program.

[0016] Policy change messages can originate from the rule management interface, the batch rule import interface, or the rule publishing data stream of the compliance system. Policy parsing scripts can use a script interpretation engine to parse rule expressions or a template-driven approach to extract field structures and logical relationships. Policy models can be stored using either relational or document-based data structures, as long as they can be retrieved by product identifier. The association between policy codes and policy execution scripts can be achieved through mapping tables or key-value mapping structures. Policy execution scripts can be stored as script files or as text in the data storage area, and are loaded and executed by the interpretation environment at runtime. Different script interpretation engines can be selected for different deployment environments, or scripts can be executed in isolated runtime environments to avoid mutual interference between rule executions. For multi-product systems, rule reuse can be achieved by adjusting the association between product identifiers and policy models, or independent policy models can be established for high-risk products to meet differentiated regulatory requirements.

[0017] In financial insurance underwriting scenarios, when regulations require new verification constraints on policyholder geographic information or document validity, the rule management terminal publishes new rule data. The strategy parsing script parses the rule data into a strategy model and associates it with the insurance product identifier. Subsequent underwriting requests can then directly locate the corresponding strategy execution script through the strategy code to complete the verification, without requiring modifications to the existing underwriting procedures.

[0018] This embodiment decouples rule expression from rule execution by parsing the rule expression into a unified strategy model and establishing a correspondence between strategy encoding and strategy execution script. Rule changes only require updating the rule data to take effect without modifying the business program, reducing the impact of rule adjustments on system stability and improving rule reuse and product adaptability.

[0019] S20, in response to the configuration request for the product identifier, obtain the corresponding strategy model according to the product identifier, and generate interface rendering data based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface; In this embodiment, responding to a configuration request for a product identifier involves receiving a query instruction from the configuration end, which includes a product identifier used to determine the scope of business products. In financial insurance systems, product identifiers are typically used to distinguish different types of insurance, different sales channels, or different versions of insurance rule sets, possessing uniqueness and searchability. Obtaining the corresponding strategy model based on the product identifier involves using the product identifier as a search condition to retrieve a set of strategy models associated with that product identifier from the strategy model storage area. The strategy model includes strategy codes and strategy configuration attributes, where the strategy configuration attributes describe the structural characteristics of the rules at the interface presentation level, including field types, field interaction methods, and display constraint information. Interface rendering data is generated based on the strategy configuration attributes of the strategy model, which involves converting the field description information in the strategy configuration attributes into a front-end recognizable data structure. This data structure describes the type, arrangement, and interactive features of interface elements. The interface rendering data, as the interface description carrier, is returned to the configuration end. The configuration end directly constructs the strategy configuration interface based on this data structure, ensuring that the configuration interface is not dependent on fixed page logic but is entirely driven by the strategy model.

[0020] Configuration requests can originate from the management workbench interface, remote configuration interfaces, or batch configuration tools. Strategy model retrieval can be achieved through relational queries or key-value mapping. Strategy configuration attributes can be described using field metadata or structured documents. Interface rendering data can be expressed in a structured data format, allowing different front-end frameworks to parse the data and generate corresponding interface elements. Different products can share parts of the strategy model, achieving differentiated interface displays through the association between product identifiers and strategy models. For products with a large number of rules, the interface rendering burden can be reduced by loading strategy models in groups. For multi-terminal access scenarios, the display specifications of different terminals can be adapted when generating interface rendering data to ensure consistency of the configuration interface.

[0021] In the scenario of configuring insurance underwriting rules, after the administrator enters the product identifier corresponding to a certain type of insurance through the workbench, the system automatically reads the strategy model associated with the product and generates interface rendering data according to the strategy configuration attributes. The workbench directly displays field selection, field constraints and interaction methods based on this data, without the need to develop separate configuration pages for different types of insurance.

[0022] This embodiment uses product identifiers to retrieve strategy models and uses strategy configuration attributes to drive interface rendering, enabling the strategy configuration interface to be dynamically generated from data structures. This reduces reliance on fixed page logic and improves configuration flexibility and product adaptability.

[0023] S30, receive business scenario parameters submitted through the policy configuration interface, generate policy filtering conditions according to the business scenario parameters, and associate and store the policy filtering conditions with the corresponding policy code; In this embodiment, receiving business scenario parameters submitted through the policy configuration interface involves reading and parsing the structured parameter data filled in and submitted by the configuration end. Business scenario parameters in a financial insurance system describe the applicable business environment for rules, such as the type of insurance source, business processing type, channel attributes, time attributes, or geographical attributes. These parameters define the scope of application for rule effectiveness. Policy filtering conditions are generated based on the business scenario parameters, which involves converting the parameter content into a conditional expression form that can be used for logical judgment. This conditional expression is used to determine whether a rule needs to be triggered in subsequent operation phases. Policy filtering conditions do not directly save the original parameters; instead, they structure the parameter relationships, parameter value ranges, and logical relationships between parameters to form computable conditional data. The policy filtering conditions are associated with and stored with the corresponding policy codes. This is achieved by using the policy codes as index identifiers to establish a direct correspondence between the generated conditional expressions and rule entities, and writing them into the storage area. This association is used in subsequent business execution phases to quickly filter out the set of rules to be executed based on the current scenario information, enabling rule triggering to have scenario selection capabilities.

[0024] Business scenario parameters can be manually selected through the interface, imported from configuration files in batches, or obtained from external configuration interfaces. Policy filtering conditions can be generated using expression structures or structured condition descriptions, as long as they are suitable for condition matching and judgment. The association between policy codes and policy filtering conditions can be achieved through mapping tables or nested storage structures. For complex business scenarios, filtering expressions with multiple condition combinations can be supported. For products where the scope of rule application frequently changes, the filtering expression can be updated by overriding old conditions. Different products can reuse the same policy code but form different filtering conditions through different business scenario parameters, achieving scenario-specific application of rules.

[0025] In insurance application processing, different verification rules may apply to application requests from different sources. After administrators select business scenario parameters such as application source and business type in the policy configuration interface, the system generates corresponding policy filtering conditions and stores them in association with policy codes. Subsequently, when processing application requests, the system can quickly determine whether the rule needs to be executed based on the scenario information carried in the request.

[0026] This embodiment transforms business scenario parameters into policy filtering conditions and associates them with policy encoding, enabling rules to be triggered according to scenarios, avoiding the execution of rules in inapplicable scenarios, and improving the flexibility and accuracy of rule usage.

[0027] S40, receive a service execution request, extract current scenario information from the service execution request, match the policy filtering conditions according to the current scenario information, and filter out a list of execution policies containing at least one target policy code; In this embodiment, receiving a business execution request involves reading request data from the insurance application processing end or the business processing end. This request contains multiple types of information related to the current business behavior. In financial insurance scenarios, business execution requests typically carry information such as the source of insurance, processing type, channel attributes, time attributes, and product identifiers. This information collectively constitutes the current scenario information. Extracting the current scenario information involves identifying and structuring relevant fields in the request data, giving the scenario-related data a unified expression form that can be used for logical judgment. Matching the current scenario information with policy filtering conditions involves comparing the structuring scenario data with the policy filtering conditions already established in the storage area, identifying rule entities that meet the condition expressions. The policy filtering conditions contain a logical description of the scenario's applicable scope. By comparing and judging, it can be determined whether the rule is applicable to the current request. Filtering out a list of execution strategies containing at least one target policy code involves extracting the policy codes that are associated with the filtering conditions after a successful match, and forming a set of execution strategies according to the matching results. This set is used to limit subsequent execution to only rules that meet the requirements of the current scenario, enabling rule execution to be triggered by the scenario.

[0028] Business execution requests can originate from the insurance application portal system, batch processing interfaces, or channel access services. Extraction of current scenario information can be achieved through field mapping or a unified data parsing module. Matching of policy filtering conditions can employ conditional expression judgment or structured condition comparison. The generation of the list of policies to be executed can ensure unique policy codes through deduplication or by sorting policies according to priority. For products with complex scenario information, multi-condition joint judgment can be supported to improve filtering accuracy. For products with a large number of rules, group matching can improve filtering efficiency.

[0029] This embodiment extracts scenario information from business execution requests and matches it with policy filtering conditions, so that rule execution is limited to the set of rules that conform to the current business environment, thereby improving the targeting and efficiency of rule execution.

[0030] S50, traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request into the target strategy execution script for execution, and obtain the strategy execution result; In this embodiment, traversing the list of strategies to be executed involves reading the set of strategy codes obtained from the previous stage one by one. This set is used to limit the scope of rules to be executed in this business process. The target strategy code serves as a unique identifier for the rule entity and is used to locate the corresponding execution logic in the script storage area. Indexing the target strategy execution script that has a relationship with the target strategy code involves performing a retrieval operation in the script storage area based on the code, reading the script content that establishes a mapping relationship with the code. This script contains the actual logical expression used to verify the data, such as field relationship judgment, numerical range judgment, or field validity judgment. Passing the data to be processed in the business execution request into the target strategy execution script for execution involves loading the relevant field data in the request into the script interpretation environment, enabling the script to perform logical operations based on the input data. The script execution process makes judgments based on the input data and the verification logic defined in the script, and finally outputs the strategy execution result. The strategy execution result is used to indicate the judgment status of the rule under the current request and the corresponding processing result information.

[0031] The list of policies to be executed can be processed sequentially or in parallel to improve efficiency. The target policy execution script can be stored as text or a script file, and is loaded and executed by the interpretation engine during runtime. Data to be processed can be written to the script execution environment via field mapping or passed through a unified data container. The script interpretation environment can use an independent running container to avoid interference between rules, or a shared running environment to improve efficiency. For a large number of rules, batch loading of scripts can reduce retrieval overhead.

[0032] This implementation separates rule execution from rule expression by locating and executing the corresponding script according to the strategy code, enabling the independent operation of rule logic and improving the flexibility and scalability of rule execution.

[0033] S60, Assemble response information based on the strategy execution result and return it.

[0034] In this embodiment, the strategy execution result originates from a set of results output by multiple target strategy execution scripts after completing the judgment of the data to be processed. Each result includes the judgment status of the current business data and the corresponding feedback content. Assembling the response information involves uniformly collecting and structuring this result set, transforming the discrete judgment results into a standard data structure recognizable by the caller. The collection process requires reading and organizing different strategy execution results, extracting the judgment status from each result, and retaining the prompt information associated with the judgment status. Structuring involves combining the extracted judgment status and prompt information into a complete data object according to a preset data organization format. Returning the data object involves sending it to the processing end that initiated the business execution request through a predetermined interaction interface to trigger subsequent business processing actions.

[0035] The results of strategy execution can be collected uniformly through a result cache, or written to the result set in real time after script execution. The assembly process can be implemented using a data serialization component or by generating a unified data format through object mapping. The return process can use a synchronous response or an asynchronous callback. For cases with a large number of results, result merging or priority determination can be performed during the assembly stage to reduce the size of the returned data.

[0036] This implementation unifies and organizes the scattered policy execution results into standard response information, realizing the centralized expression of rule judgment results, which makes it convenient for callers to directly use the judgment results for subsequent business processing.

[0037] In one embodiment, step S10 above includes: S101, Listen to the business message queue. When a policy change message is captured, load the stored policy parsing script based on the operation type of the policy change message. S102, run the stored policy parsing script to perform field mapping logic on the policy change message and extract the policy code, policy configuration attribute and product identifier; S103, encapsulate the policy code and the policy configuration attributes to generate a policy model; S104, establish a mapping relationship between the strategy model and the product identifier and store them together, and retrieve the pre-stored strategy execution script according to the strategy code, and establish an association relationship between the strategy code and the pre-stored strategy execution script.

[0038] In this embodiment, the business message queue is used to carry out the asynchronous delivery and consumption of policy change messages. After adjusting the insurance verification constraints, regulatory reporting element constraints, and pre-issuance information verification element constraints, the configuration end encapsulates the changed content into a policy change message and writes it to the business message queue. Listening to the business message queue involves establishing a continuous pull or push subscription mechanism on the consumer side, configuring a consumer group identifier to avoid duplicate consumption, and recording the message identifier and reception time for each message to facilitate orderly processing of change delivery during peak insurance periods. After capturing the policy change message, the message header and message body are read. The message header carries the operation type, which describes the category of the change behavior, such as add, update, delete, deactivate, enable, etc. It can also carry a version number or effectiveness flag to distinguish different release batches of the same policy code. Loading the stored policy parsing script based on the operation type involves selecting the corresponding parsing entry point according to the operation type. Add and update types correspond to the complete parsing process, delete and deactivate types correspond to the index positioning and status update process, and enable types correspond to the status recovery and association completion process. The loading action involves reading the script content from the script storage area and verifying the script identifier and script verification value. After the verification is successful, the script content is loaded into the script interpretation environment. The script interpretation environment provides runtime isolation, timeout limits, resource quotas, and exception handling, so that script execution will not affect the continuity of message consumption.

[0039] The stored policy parsing script is run to perform field mapping logic on the policy change message. This logic converts the field names, types, and value structures in the change message into an internal unified field set. Field mapping includes field name mapping, type mapping, enumeration mapping, and default value filling. Field name mapping maps external configuration field identifiers to internal field keys; type mapping maps external type descriptions to internal type tags; enumeration mapping maps external enumeration values ​​to an internal recognizable enumeration set; and default value filling fills in the required field set when the change message lacks optional fields. Policy encoding extraction involves reading the encoded field from the change message to uniquely identify the policy entity, and performing length, character set, and duplicate checks on the encoded field. Duplicate checks determine whether a policy model record with the same policy encoding already exists under the same product identifier. Extracting strategy configuration attributes involves reading a set of attributes from change messages that describe strategy configuration behavior. This set covers field types, field options, field constraint descriptions, and display-related attributes. Field options express a set of possible values ​​or a range of interactive values, while field constraint descriptions express constraints such as non-empty, range limitations, and dependencies. Extracting product identifiers involves reading product dimension identifiers from change messages. Product identifiers distinguish configuration sets under different insurance types, channel versions, and regulatory reporting standards, and serve as one of the primary search criteria for subsequent storage and retrieval.

[0040] The encapsulation of strategy codes and strategy configuration attributes to generate strategy models involves assembling the extracted codes and attribute sets into a strategy model object according to a predefined data structure. The strategy model includes strategy code fields and strategy configuration attribute fields, and may also include version fields, effectiveness flag fields, update time fields, and release source fields to support financial compliance audits and backtracking. After the strategy model object is generated, a consistency check is performed, covering strategy code non-empty checks, strategy configuration attribute structure integrity checks, and field option and field type consistency checks, preventing mismatches between field options and field types that could lead to subsequent configuration-side rendering anomalies. Establishing a mapping relationship between strategy models and product identifiers and associating them with storage involves writing a mapping record from product identifiers to strategy models in the storage area. This mapping record can use the product identifier as the partition key and the strategy code as the sort key, enabling quick retrieval of strategy model sets under the same product identifier by strategy code. The associated storage actions include writing the strategy model main record, writing the product identifier mapping record, and writing the version index record. The version index record is used to manage different versions of the same strategy code, avoiding overwrite conflicts during concurrent releases. Before storage, idempotency checks are performed on the message identifier. Idempotency checks are used to identify duplicate delivery or consumption scenarios. Processed messages directly return the processing result and skip duplicate writing, reducing storage pressure in high-concurrency environments.

[0041] Retrieving pre-stored policy execution scripts based on policy codes involves searching for corresponding script content or script reference identifiers in the script storage area using the policy code as the search condition. The script storage area can be indexed by policy code, ensuring that retrieval can be completed within a controllable timeframe even with a large number of script records. The search results include the script identifier, script checksum, script version, and script loading parameters. The script loading parameters describe the runtime constraints and input field list of the script interpretation environment. The input field list aligns with the field constraint descriptions in the policy configuration attributes to prevent the script from failing to read necessary fields during runtime. Establishing the association between policy codes and pre-stored policy execution scripts involves writing a mapping record from policy code to script identifier, and adding a version number and an activation flag to the mapping record. The activation flag is used to set the association to an unavailable state when the policy change message is a disabled or deleted category. After the association is written, an association integrity check is performed to confirm that each policy code has a usable script mapping. If no script is found, the missing status is recorded and a processing alarm message is output, allowing financial risk control personnel to complete the necessary steps before insurance application, preventing unexecutable code mappings after an insurance application request is received.

[0042] This embodiment accesses policy change messages through a business message queue, uses operation type to drive the loading of parsing scripts, completes the extraction of policy codes, policy configuration attributes, and product identifiers, and generates policy models. It also associates and stores product identifier mappings and policy code script mappings, forming a searchable and stable correspondence between policy release and execution logic. This supports rapid database storage and traceable management of high-frequency policy changes in financial and insurance scenarios, reducing the risk of execution inconsistencies caused by configuration updates.

[0043] In one embodiment, step S20 above includes: S201, Receive a configuration request for product identifier initiated by the front-end workbench, and parse the configuration request to obtain the product identifier; S202, using the product identifier as the search condition, query the database to obtain at least one strategy model associated with the product identifier; S203, Traverse the obtained strategy model, read the strategy configuration attributes in the strategy model, and obtain the component type, field options and display order information; S204, Assemble the component types and field options according to the display order information to generate interface rendering data; S205, the interface rendering data is returned to the front-end workbench, and the front-end workbench configures the interface based on the rendering strategy of the interface rendering data.

[0044] In this embodiment, the front-end workbench's initiation of a configuration request for a product identifier is manifested as the configuration entry submitting a query command to the back-end configuration service. The configuration request carries a product identifier field and request metadata. The request metadata describes elements such as the current configuration view of the workbench, the operator's permission scope, and the display language environment, facilitating the back-end to perform field set pruning and display attribute selection when generating interface rendering data. Parsing the configuration request to obtain the product identifier involves structured decoding and field extraction of the request message. The decoding process includes request format verification, field existence verification, and field validity verification. Validity verification covers character set constraints, length constraints, and null value constraints to prevent abnormal identifiers from entering the retrieval stage and causing data scanning expansion. In financial insurance scenarios, product identifiers typically correspond to insurance type versions, channel versions, or regulatory versions. The product identifier, as a retrieval condition, directly determines the range of strategy model sets read. The parsing stage can also perform access control judgments on the product identifier based on the permission scope to prevent unauthorized queries of rule configuration sets that should not be exposed.

[0045] The database query, using product identifiers as search criteria, retrieves at least one strategy model associated with that product identifier. This is achieved by retrieving the strategy model record set from the indexed mapping table or the partition key of the strategy model table. The database query consists of two parts: retrieving the mapping record from the product identifier to the strategy model and retrieving the main record of the strategy model. The mapping record is used to locate the set of strategy model keys, and the main record is used to obtain the strategy configuration attribute content. The retrieval process can include an activation flag condition and a version condition in the query statement. The activation flag condition is used to filter out deactivated or unreleased strategy model records, and the version condition is used to select the currently valid version when multiple versions coexist, avoiding misuse of configurations due to expired rules displayed on the workbench. To support fast workbench response, the query process can read the strategy model set in pages or by display group. Page reading avoids loading a large number of strategy models at once, resulting in an excessively large response volume, while reading by display group facilitates the workbench to present configuration entry points according to business domains or risk domains.

[0046] The process of traversing the acquired strategy model and reading its configuration attributes involves parsing each record in memory according to the strategy model's record set. The strategy configuration attributes, as a structured set of fields, provide the descriptive information required by the interface. Component types indicate the category of UI elements to be generated by the front end. Categories can cover structural units such as input boxes, selection boxes, date pickers, text prompts, and segmented containers. The source of component types is the definition of field interaction forms in the strategy configuration attributes. Field options describe the set of optional values ​​or the range of values. The range of values ​​can be represented as an enumeration set, a range description, or a dependent set of options. The source of field options is the definition of the field's value domain in the strategy configuration attributes. Display order information describes the arrangement order of the strategy models within the same product identifier configuration interface. Display order information can come from the explicit order field in the strategy configuration attributes, or from the sorting key or priority field of the strategy model record. During the reading phase, the display order information needs to be normalized to a comparable sorting value to facilitate stable sorting during subsequent assembly. The traversal phase can also generate auxiliary descriptive information such as field display names, field value type markers, required field markers, and editable markers. This information also comes from the strategy configuration properties and is used to guide the workbench in rendering the interactive state and the location of the verification prompts, reducing display differences caused by the workbench inferring on its own.

[0047] Assembling component types and field options according to their display order to generate UI rendering data involves sorting and structurally encapsulating the traversed descriptive elements. The sorting stage uses the display order as the sorting key, supporting secondary sorting keys with the same sequence number to maintain result stability. Secondary sorting keys can use strategy encoding or field identifiers to avoid inconsistent return orders of elements with the same sequence number in different query batches, which could cause UI jumps. The assembly stage combines each component type with its field options, field value type markers, and interaction restriction descriptions into rendering nodes. Multiple rendering nodes form a rendering node set based on the sorting result. The rendering node set can be further grouped into a group structure. Group markers can come from the classification descriptions of risk domains, compliance domains, and insurance element domains in the strategy configuration attributes, presenting the workbench according to financial risk control management practices. The UI rendering data is output in a structured data format, containing fields such as the rendering node set, group structure, default value expression, and validation prompt expression. All data fields are derived from the strategy configuration attributes in the strategy model, avoiding hard-coding of field mappings to controls in the workbench.

[0048] The UI rendering data is returned to the front-end workbench, which then uses this data to configure the rendering strategy. This is represented by back-end outputting descriptive data that directly drives rendering to the workbench. The workbench generates UI elements and completes the layout based on this descriptive data. The return process includes response message encapsulation, data integrity verification, and response size control. Data integrity verification ensures that each rendering node contains necessary fields such as component type, field options, and display order information. Response size control prevents workbench lag when returning a set of rendering nodes in pages when there are many strategy models. During the workbench rendering phase, corresponding UI elements are instantiated based on component type, optional lists or value range prompts are generated based on field options, the element arrangement order is determined based on display order information, and interaction restrictions are set based on required and editable tags. Financial compliance personnel configure field constraints, value domains, and applicable scopes through the strategy configuration interface, providing a structured entry point for subsequent business scenario parameter submissions.

[0049] This embodiment uses a product identification positioning strategy model and reads strategy configuration attributes to generate interface rendering data containing component type, field options, and display order information. The front-end workbench can render the strategy configuration interface according to a unified data structure, reducing the workload of interface customization for different products and improving the consistency and maintainability of rule configuration entry.

[0050] In one embodiment, step S30 above includes: S301, Obtain the business scenario parameters selected for the target strategy on the strategy configuration interface. The business scenario parameters include connection method information, business source information and business type information. S302, in response to the submission operation initiated by the strategy configuration interface, perform approval processing on the configuration request containing the business scenario parameters, and extract the approved business scenario parameters after approval; S303, logically encapsulate the approved business scenario parameters to generate policy filtering conditions that can be recognized by machines; S304, obtain the policy code corresponding to the target policy, establish a mapping relationship between the policy filtering conditions and the policy code, and write the mapping relationship and the policy filtering conditions into the policy filtering configuration table.

[0051] In this embodiment, the strategy configuration interface is used to carry the configuration input for the scope of rule application. The configuration input revolves around the target strategy, which is presented as an option on the interface and maintains a traceable correspondence with the strategy code in the strategy model. Obtaining the business scenario parameters selected for the target strategy on the strategy configuration interface is reflected in the aggregation of the values ​​of the interface controls before submission, organizing the set of values ​​corresponding to the same target strategy into a structured parameter object. The business scenario parameters include connection method information, business source information, and business type information. Connection method information describes the access method of the request entering the verification domain, business source information describes the source channel or source system of the request, and business type information describes the business action category of the current request. These three types of information serve as key dimensions of the scope of rule application, enabling the same strategy code to be effective only in specific financial business scenarios, avoiding triggering in irrelevant business scenarios. During the acquisition phase, format constraints and value domain constraints can also be applied to each field. Value domain constraints come from field options or configuration dictionaries to avoid unrecognizable source values ​​that would render subsequent filtering conditions unusable.

[0052] In response to submissions initiated through the strategy configuration interface, the approval process for configuration requests containing business scenario parameters is implemented by introducing approval control before the configuration request enters persistence, ensuring that configuration changes comply with financial compliance requirements. Upon triggering a submission, a configuration request record is generated. This record includes the target strategy identifier, business scenario parameter content, submitter identifier, submission time, and change summary. The change summary records differences in integration method information, business source information, and business type information. Approval processing is completed through an approval flow engine. The engine determines the approval path based on factors such as product identifier, the risk domain of the target strategy, and change level. The approval path consists of approval nodes, each containing an approver identifier and an approval action identifier. During the approval process, approval results and opinions are recorded. Approval results distinguish between states such as approved, rejected, and withdrawn. Upon approval, the approved business scenario parameters are extracted. This involves reading the approved set of values ​​from the configuration request record and extracting the approval status and version identifier. The version identifier distinguishes different configuration batches of the same target strategy, preventing overwriting conflicts caused by concurrent submissions.

[0053] The approved business scenario parameters are logically encapsulated to generate machine-recognizable policy filtering conditions. This is manifested in converting interface method information, business source information, and business type information into a unified condition expression structure. Logical encapsulation includes field normalization, condition item construction, and condition combination. Field normalization maps fields from different sources to internal condition field keys. Condition item construction forms a triple structure of field key, comparison operator, and value set. Condition combination organizes multiple condition items into an executable expression according to logical relationships. Comparison operators can express equality matching, inclusion matching, range matching, etc., and value sets can express single-value, multi-value, or range descriptions. The expression structure of the policy filtering conditions needs to satisfy the decidability of subsequent matching stages. Therefore, the encapsulation stage also requires standardization of the condition expression. Standardization includes deduplication, null value removal, conflict detection, and short-circuit simplification. Conflict detection identifies mutually exclusive combinations of interface method information, business source information, or business type information. Short-circuit simplification eliminates redundant condition items when the condition item can uniquely define the scenario, preventing overly complex policy filtering conditions from affecting matching efficiency.

[0054] Obtaining the strategy code corresponding to the target strategy involves establishing a stable reference between the target strategy and the strategy model. This acquisition operation maps the target strategy identifier passed through the interface to the strategy model record, reads the strategy code field from the strategy model, and verifies the uniqueness of the strategy code within the current product identifier range when necessary. Establishing the mapping relationship between strategy filtering conditions and strategy codes involves using the strategy code as the index key and the expression structure of the strategy filtering conditions as the index value or reference value, writing it into the mapping record. In addition to the strategy code and strategy filtering conditions, the mapping record may also include an effectiveness flag, version identifier, approval record reference, and update time. The effectiveness flag controls whether the mapping record participates in subsequent matching, the version identifier enables rollback and audit trails, and the approval record reference maintains the association between the configuration source and the approval conclusion. Writing the mapping relationship and strategy filtering conditions into the strategy filtering configuration table is a persistent database write operation. The strategy filtering configuration table uses the strategy code as the retrieval dimension and retains standardized storage fields for interface method information, business source information, and business type information, facilitating querying and difference comparison on the configuration management end. During the write phase, version archiving or state switching can be performed on the historical records of the same policy code to avoid ambiguity in the matching phase caused by multiple effective mapping records marked as available for the same policy code.

[0055] This embodiment generates policy filtering conditions by collecting information on the connection method, business source, and business type through the policy configuration interface and processing it through approval. Then, the policy filtering conditions are mapped to the policy codes and written into the policy filtering configuration table. This makes the scope of application of the rules have a configuration expression that can be approved, versioned, and searched, which facilitates the configuration management of selecting rules according to scenarios in financial business scenarios.

[0056] In one embodiment, step S40 above includes: S401, parse the received business execution request, and extract the current scenario information, including the interface channel identifier, business type identifier, and business source attribute, from the context of the business execution request; S402, Access the policy filtering configuration table and retrieve the policy filtering conditions stored in the policy filtering configuration table; S403, The current scene information is logically compared with each policy filtering condition to identify the matching policy filtering condition. S404, obtain the policy code associated with the matched policy filtering condition as the target policy code, and generate a list of policies to be executed containing at least one target policy code.

[0057] In this embodiment, the business execution request carries triggering information for financial business actions such as insurance application processing, policy maintenance processing, claims pre-verification, and electronic contract issuance pre-verification. The context of the business execution request carries a set of scenario fields related to the current business action and a set of data fields to be processed. Parsing the received business execution request involves structured decoding and field extraction of the request message. During the decoding phase, the request format, field boundaries, and field types are verified, converting the original request into an accessible context object. The context object extracts the interface channel identifier, business type identifier, and business source attribute to form the current scenario information. The interface channel identifier identifies the access end category or access channel identifier, distinguishing access sources such as direct connection interfaces, aggregation channels, and cooperative platforms, facilitating the differentiation of different access strategy sets under the same product. The business type identifier identifies the business action category, distinguishing action domains such as insurance application, renewal, change, and pre-issuance confirmation, ensuring consistency between rule triggering and business actions. The business source attribute expresses the attribution attribute of the business initiation source, such as marketing source, counter source, and cooperative source, allowing rule triggering to be differentiated according to source attribute. During the extraction phase, normalization processing can be performed on three types of fields. Normalization processing includes dictionary mapping, null value normalization, and case normalization. Dictionary mapping is used to map heterogeneous values ​​passed in from different access terminals to a unified identifier. Null value normalization is used to convert missing fields into a unified default expression to avoid undeterminable states in subsequent comparisons.

[0058] Accessing the policy filtering configuration table and retrieving each policy filtering condition involves reading the mapping set of policy codes and policy filtering conditions from the storage area. During the access phase, product identifiers or business domain identifiers are used as search criteria to limit the scope, avoiding the expansion of the matching set due to reading policy filtering conditions for irrelevant products. The retrieval phase reads the structured expression of the policy filtering conditions. This structured expression includes a set of condition items, logical combinations, an activation flag, and a version identifier. The activation flag is used to filter deactivated or invalid records, and the version identifier is used to select valid records when multiple versions coexist. To adapt to the high concurrency of financial business, the retrieval phase can adopt batch reading or index-based reading. Batch reading controls the amount of data read in a single session, while index-based reading pre-filters the candidate condition set by the interface channel identifier or business type identifier, reducing the number of comparisons in subsequent logical comparisons.

[0059] The logical comparison between the current scene information and each policy filtering condition is manifested as performing a judgment operation on the condition expression. The logical comparison uses the current scene information as the input set, extracts each condition item from the policy filtering conditions, and compares it with the corresponding field in the input set. The comparison process performs matching judgments based on the comparison operator in the condition item and the value set. Equality matching checks whether a field value belongs to the value set; inclusion matching checks whether a field value contains a specified fragment or belongs to the intersection of multiple value sets; range matching checks whether a field value falls within a range expression. Logical combination relations are used to organize the judgment results of multiple condition items, supporting combinations of conjunction and disjunction. Conjunction requires multiple conditions to be satisfied simultaneously, while disjunction allows any condition to be satisfied. The logical comparison outputs a matching flag, which indicates whether the current policy filtering condition is consistent with the current scene information. Identifying the matched policy filtering conditions is manifested by filtering the set of policy filtering conditions with the matching flag set as satisfied after the logical comparison, and performing consistency processing on the set, including deduplication, conflict detection, and priority adjudication. Deduplication is used to merge results when duplicate condition records exist. Conflict detection is used to identify multiple condition records that simultaneously meet the same policy code. Priority adjudication is used to select the target record when conflict detection is successful. Priority can come from the display order information, version identifier, or effective time field. The adjudication result is used to ensure that each policy code corresponds to a unique condition source in this filtering.

[0060] The process of retrieving the policy code associated with the matched policy filtering conditions as the target policy code involves reading the policy code field from the mapping record in the matching set and constructing the target policy code set from this set of fields. The target policy code set represents the set of rule codes that need to be triggered in this business execution request. Generating a list of policies to be executed, each containing at least one target policy code, involves organizing the target policy code set into a list structure according to a predefined order. This order can be based on a priority field or display order information, and the sorting is used to form a stable execution sequence in subsequent execution phases. The generation phase of the list of policies to be executed can include a check for list integrity. This integrity check confirms that the list is not empty and that each target policy code has an executable status marker, preventing invalid codes from being included in the execution scope and causing subsequent unexecutable states.

[0061] This embodiment extracts the interface channel identifier, business type identifier, and business source attribute from the context of the business execution request to form the current scenario information. It then retrieves the policy filtering conditions from the policy filtering configuration table for logical comparison to obtain the target policy code that matches the current scenario information and generates a list of policies to be executed. This enables the rule filtering to be precisely limited according to the financial business scenario, reduces irrelevant rules from entering the execution scope, and improves the stability and controllability of the filtering.

[0062] In one embodiment, step S50 above includes: S501, Traverse the list of strategies to be executed and read the target strategy code one by one; S502, based on the association between the target policy code and the policy execution script, a retrieval is performed to obtain the target policy execution script that is associated with the target policy code; S503, construct a script execution environment for the target strategy execution script, and load the data to be processed in the business execution request into the script execution environment; S504, run the target policy execution script in the script execution environment to obtain the corresponding policy execution result.

[0063] In this embodiment, the list of strategies to be executed carries the set of strategy codes to be executed after scenario screening. Traversing the list of strategies to be executed and reading the target strategy codes one by one is reflected in sequential scanning or priority scanning of the list. During reading, each target strategy code is loaded into the execution context variable and the current traversal position is recorded. Traversal control information is used to support abnormal retries and result backfilling. The target strategy code serves as an index key for subsequent retrieval. During the reading phase, the target strategy code can be validated. Validity validation covers null value validation, format validation, and availability status validation. Availability status validation is achieved by querying the effective flag in the association relationship between the strategy code and the strategy execution script, avoiding invalid codes from entering the script execution phase and resulting in a state where no script is available. During the traversal phase, a batch identifier to be executed can be generated. The batch identifier is formed by combining the business execution request identifier and the traversal sequence number, which is used to stably bind the strategy execution result with the target strategy code, facilitating the backtracking of rule execution details for a single insurance verification by financial compliance audit.

[0064] The retrieval based on the association between the target policy code and the policy execution script is manifested by accessing the mapped storage area using the target policy code as the search condition, and retrieving the location information of the target policy execution script from the mapping record. The location information of the association may include the script identifier, script version, script storage location, and script checksum. The script identifier is used to uniquely locate the script entity; the script version is used to select the valid version when multiple versions of the same target policy code exist; the script storage location is used to read the script content or reference; and the script checksum is used to verify that the script content has not been tampered with before loading. The retrieval process performs a consistency check on the mapping records, covering both the unique matching check of the target policy code and the unique matching check of the script version, avoiding ambiguity in script selection caused by multiple effective mapping records corresponding to the same target policy code. If the mapping record contains a loading parameter set, the loading parameter set is used to limit the set of input fields and resource quotas accessible during script runtime. The set of input fields is aligned with the field list of the data to be processed, and the resource quota is used to limit the computing resources occupied by the script execution, avoiding increased resource contention in high-concurrency insurance scenarios.

[0065] The script execution environment for the target policy execution script is constructed by providing an isolated runtime container and a controlled variable space for script execution. The script execution environment includes a script interpreter instance, a variable binding area, and a set of runtime constraints. The script interpreter instance parses and executes the target policy execution script. The variable binding area stores the data to be processed and intermediate variables generated during execution. The set of runtime constraints limits the maximum runtime, maximum memory usage, and the set of accessible external functions. During the construction phase, the target policy execution script is loaded into the script interpreter instance and subjected to syntax and entry point validation. Syntax validation identifies incomplete script content or illegal structures, while entry point validation confirms that the script contains an executable entry point definition to prevent runtime failures. Writing the data to be processed from the business execution request into the script execution environment involves field mapping and type normalization of the data. Field mapping maps field names in the data to variable names recognizable by the script, and type normalization converts numeric, date, and enumeration fields into data types that the script interpreter can process. The writing process performs integrity checks on key fields. The integrity checks are determined based on the set of loading parameters of the target policy execution script. Missing fields are filled with default values ​​or written to the variable binding area with missing flags, so that the script can determine the missing status internally and avoid directly throwing exceptions that affect the execution of the entire batch of rules.

[0066] The execution of the target strategy script within the script execution environment results in the invocation of the script interpreter instance and the generation of an output object. During execution, execution timeouts and resource usage are controlled by a set of execution constraints. Timeouts trigger an exception status and terminate execution. Resource usage exceeding a threshold triggers degradation processing and returns to a controlled exception status. The strategy execution result is expressed as a structured result object, which includes at least a judgment status marker and a cause information marker. The judgment status marker expresses the current target strategy code's judgment conclusion on the data to be processed, while the cause information marker expresses the prompt message or verification item identifier when conditions are not met. The strategy execution result is written to a result set and bound to the target strategy code and batch identifier. This binding relationship is used to accurately aggregate multi-strategy execution outputs in the subsequent response information assembly stage. To support financial risk control auditing, the execution phase can also record the script version, execution start time, execution end time, and input field summary. The input field summary performs anonymization and abstraction processing on the data to be processed, avoiding the plaintext storage of sensitive insurance information in the execution log.

[0067] This embodiment reads the target strategy code by traversing the list of strategies to be executed and retrieves the target strategy execution script according to the association relationship. The data to be processed is written into the script execution environment and the target strategy execution script is run to obtain the strategy execution result. This enables each target strategy code to correspond to a controllable script execution instance, supporting the precise execution of rules by code in financial insurance verification scenarios and forming traceable execution output.

[0068] In one embodiment, step S60 above includes: S601, summarizes the policy execution results generated by running all target policy execution scripts; S602, extract the feedback status and corresponding prompt text from the summarized strategy execution results; S603, according to the interface specifications required by the business system that initiated the business execution request, the feedback status and corresponding prompt text are encapsulated into response information; S604, the response information is fed back to the business system.

[0069] In this embodiment, the strategy execution result originates from the output of the target strategy execution script. The aggregation of all strategy execution results generated by the execution of all target strategy execution scripts is represented by grouping the scattered result objects into a single result set according to the business execution request dimension. The aggregation process uses the business execution request identifier as the aggregation key, writing the strategy execution result corresponding to each target strategy code into an aggregation container. The aggregation container simultaneously records the target strategy code, script version identifier, and generation timestamp to avoid result mismatches caused by concurrent execution or asynchronous write-back. During the aggregation phase, an integrity check is performed on the result set. The integrity check compares the result set with the target strategy code set in the list of strategies to be executed, confirming that each target strategy code has a corresponding strategy execution result record. If a record is missing, a missing record flag and a missing reason flag are written. The missing reason flag is used to distinguish states such as script retrieval failure, script execution timeout, and controlled termination due to missing input fields, ensuring that the subsequent encapsulation stage can output interpretable feedback states rather than blank results.

[0070] Extracting feedback status and corresponding prompts from the aggregated strategy execution results involves reading and normalizing the structured fields of each strategy execution result. Feedback status represents the set of statuses output by the rule judgment, covering states such as pass, fail, abnormal, and missing. Normalization maps status fields from different script versions to a unified set of status codes, facilitating consistent processing across different products and channels in the insurance application process. Prompts provide textual explanations for the corresponding statuses. These explanations can originate from script output fields or from a mapping table between strategy codes and prompt templates. The mapping table is indexed by strategy codes. Prompt templates support parameter placeholders, filled with field values ​​from the strategy execution results. Sensitive fields are anonymized during the filling process to prevent insurance information from being exposed in the returned text. The extraction phase can also generate strategy-level result entries, containing the target strategy code, feedback status, prompts, and associated field identifiers. These identifiers point to the set of fields that trigger verification, enabling the business system to locate problematic fields in page prompts or risk control audits.

[0071] According to the interface specifications required by the business system that initiated the business execution request, the feedback status and corresponding prompt text are encapsulated into response information and serialized and assembled based on the response structure defined by the business system. The interface specification defines the field set, field type, field hierarchy, and encoding method of the response information. The encapsulation process constructs the response root object according to the interface specification, writes the policy-level result items into the detail fields, and generates summary fields. The summary fields can include the overall judgment status, the overall prompt text set, or the overall blocking flag. The overall judgment status is generated by the policy-level feedback status according to predefined aggregation logic. The aggregation logic can be implemented using a status priority table, which defines the coverage order of abnormal and failure statuses during aggregation, avoiding contradictions between multiple rule outputs that lead to an uncertain overall status. The interface specification may also require the return of tracking fields, which include the business execution request identifier, product identifier, and processing timestamp. The processing timestamp is used to measure the verification processing time and support reconciliation and auditing. During the encapsulation phase, format validation and length control are performed on the response information. Format validation is used to confirm that the field types and levels conform to the interface specifications, and length control is used to limit the number of prompt text sets and detailed items. When the limit is exceeded, the response is pruned according to priority and the pruning mark is retained to avoid the response body being too large and affecting the throughput of the insurance system.

[0072] Feeding response information back to the business system involves transmitting the response information back to the business system that initiated the business execution request through a predetermined communication channel. The feedback process writes the response information into a response message, attaching a status code and a signature field. The signature field is used by the business system to verify that the response content has not been tampered with, and the status code is used by the business system to distinguish between business judgment failure and processing anomalies. The feedback phase records the correspondence between the response sending result and the business execution request identifier. The sending result includes success, failure, and retry status. The retry status is used to trigger controlled retransmission when there are network fluctuations or the business system is temporarily unavailable, and the resource consumption caused by repeated sending is limited through a retry limit and backoff strategy. To meet financial compliance audit requirements, the feedback phase can also record a response information summary. The summary anonymizes and compresses the prompt text and statistically records the feedback status, ensuring that the audit record reflects the rule execution conclusion without exposing sensitive insurance information.

[0073] For example, taking health insurance underwriting as an example, the business side maintains pre-insurance verification constraints on the product operation platform, involving aspects such as the completeness of insurance information, consistency of regulatory reporting elements, channel access restrictions, and restrictions on insurance methods. When the product side adds or modifies a verification constraint, it forms a policy change message by defining the relevant content of the interface and writes it to the business message queue. Rule configuration personnel write or modify the policy parsing script in the rich text editor on the page, enabling the policy parsing script to extract fields such as policy code, policy configuration attributes, and product identifier from the policy change message, and store the policy parsing script in the script storage area; at the same time, they write a policy execution script to implement the verification logic corresponding to the policy code, store the policy execution script in the script storage area, and keep it searchable. After the business message queue is listened to, the policy change message is captured, the policy parsing script is loaded and run, and the parsing result is encapsulated into a policy model. The policy model contains the policy code and policy configuration attributes. The policy model is associated with the product identifier and stored accordingly. The policy code is associated with the pre-stored policy execution script, and in the subsequent operation phase, the target policy execution script can be directly retrieved based on the policy code.

[0074] The business side initiates a configuration request for a product identifier on the front-end workbench, such as by inputting a health insurance product code or channel version code. The configuration request is parsed to obtain the product identifier. The back-end uses the product identifier as a search condition to query the database and retrieve the set of strategy models associated with the product identifier. The workbench needs to display all configurable validation items for the product. The back-end traverses the strategy models to read the strategy configuration attributes, obtaining component types, field options, and display order information. The component type determines the category of interface elements rendered by the workbench, the field options generate a set of optional values, and the display order information determines the order of the interface. The back-end assembles the component types and field options according to the display order information, generates interface rendering data, and returns it to the front-end workbench. The front-end workbench renders the strategy configuration interface based on the interface rendering data. In the strategy configuration interface, configuration personnel select business scenario parameters for the target strategy. Business scenario parameters include integration method information, business source information, and business type information. For example, integration method information distinguishes between API integration and H5 integration, business type information distinguishes between new and renewal policies, and business source information distinguishes between direct sales channels, bancassurance channels, and internet cooperation channels.

[0075] After submitting the configuration request through the strategy configuration interface, the request enters the approval process. The approval workflow verifies the business scenario parameters. Once approved, the approved business scenario parameters are extracted and logically encapsulated to generate machine-recognizable strategy filtering conditions. Subsequently, the strategy code corresponding to the target strategy is obtained, and a mapping relationship between the strategy filtering conditions and the strategy code is established. This mapping relationship and the strategy filtering conditions are written into the strategy filtering configuration table, allowing the same strategy code to be selectively triggered under different integration methods, business source information, and business type information. For example, a product might trigger a high-risk field consistency check when applying for new insurance and integrating via H5, but not when renewing or integrating via API; another product might add an additional insurance information consistency check when sourced from internet cooperation channels, but not perform this check when sourced from a counter.

[0076] When an insurance application enters the underwriting stage and requires verification, the business system initiates a business execution request. This request carries the data to be processed and the scenario fields from the context. After the business execution request is parsed, the current scenario information, including the interface channel identifier, business type identifier, and business source attribute, is extracted from the context of the request. The interface channel identifier corresponds to the interface method information, the business type identifier corresponds to the business type information, and the business source attribute corresponds to the business source information. The runtime accesses the policy filtering configuration table, retrieves the stored policy filtering conditions, logically compares the current scenario information with each policy filtering condition, identifies matching policy filtering conditions, and then obtains the policy code associated with the matching policy filtering condition as the target policy code, generating a list of policies to be executed containing at least one target policy code. Once the list of strategies to be executed is determined, the execution phase begins. This involves traversing the list and reading the target strategy code for each strategy. Based on the association between the target strategy code and the strategy execution script, a search is performed to obtain the target strategy execution script that is associated with the target strategy code. A script execution environment is then constructed for each target strategy execution script. The data to be processed in the business execution request is written into the script execution environment, and the target strategy execution script is run in the script execution environment to obtain the corresponding strategy execution result. After the strategy execution result is generated, the return phase begins. The strategy execution results generated by the target strategy execution script are summarized. Feedback status and corresponding prompts are extracted from the summarized strategy execution results. Following the interface specifications required by the business system that initiated the business execution request, the feedback status and corresponding prompts are encapsulated into response information, which is then fed back to the business system. Based on this, the business system decides whether to continue issuing electronic contracts, whether to prompt users to supplement insurance elements, whether to require manual review, or to directly intercept the issuance of the policy. This allows for rapid adjustment and scenario-based activation of pre-insurance verification constraints without altering the business program release schedule.

[0077] This embodiment collects and verifies the strategy execution results, extracts the feedback status and prompt text, and then encapsulates them into response information according to the interface specifications of the business system and feeds it back. This enables the multi-strategy verification outputs to form a unified return structure, which facilitates consistent processing of the business system in the insurance application and electronic contract issuance stages and reduces the risk of result mismatch.

[0078] In one embodiment, a business strategy configuration and execution apparatus is provided, which corresponds one-to-one with the business strategy configuration and execution method described in the above embodiments. (Refer to...) Figure 3 , Figure 3 This is a schematic diagram of the functional modules of a preferred embodiment of the business strategy configuration and execution device of the present invention. The modules include a strategy modeling module 10, an interface rendering data generation module 20, a strategy filtering construction module 30, a strategy screening module 40, a strategy execution scheduling module 50, and a result encapsulation module 60. Detailed descriptions of each functional module are as follows: The strategy modeling module 10 is used to receive strategy change messages, call the stored strategy parsing script to parse the strategy change messages, generate a strategy model containing strategy codes and strategy configuration attributes, and store the strategy model in association with the product identifier. The strategy code is associated with a pre-stored strategy execution script. The interface rendering data generation module 20 is used to respond to a configuration request for a product identifier, obtain the corresponding strategy model based on the product identifier, and generate interface rendering data based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface. The strategy filtering construction module 30 is used to receive business scenario parameters submitted through the strategy configuration interface, generate strategy filtering conditions according to the business scenario parameters, and associate and store the strategy filtering conditions with the corresponding strategy code. The strategy filtering module 40 is used to receive a business execution request, extract current scenario information from the business execution request, match the strategy filtering conditions according to the current scenario information, and filter out a list of execution strategies containing at least one target strategy code. The strategy execution scheduling module 50 is used to traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request to the target strategy execution script for execution, and obtain the strategy execution result. The result encapsulation module 60 is used to assemble response information based on the strategy execution result and return it.

[0079] For specific limitations regarding the business strategy configuration and execution device, please refer to the foregoing limitations on the business strategy configuration and execution method, which will not be repeated here. Each module in the aforementioned business strategy configuration and execution device can be implemented entirely or partially through software, hardware, or a combination thereof. These modules can be embedded in or independent of the processor in the computer device in hardware form, or stored in the memory of the computer device in software form, so that the processor can call and execute the operations corresponding to each module.

[0080] In one embodiment, a computer device is provided, which may be a server, and its internal structure diagram may be as follows: Figure 4As shown, the computer device includes a processor, memory, network interface, and database connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile and / or volatile storage media and internal memory. The non-volatile storage media stores the operating system, computer programs, and database. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with external clients via a network connection. When the computer program is executed by the processor, it implements a business strategy configuration and execution method, or server-side functions or steps.

[0081] In one embodiment, a computer device is provided, which may be a client, and its internal structure diagram may be as follows: Figure 5 As shown, the computer device includes a processor, memory, network interface, display screen, and input devices connected via a system bus. The processor provides determination and control capabilities. The memory includes non-volatile storage media and internal memory. The non-volatile storage media stores the operating system and computer programs. The internal memory provides an environment for the operation of the operating system and computer programs in the non-volatile storage media. The network interface is used to communicate with an external server via a network connection. When the computer program is executed by the processor, it implements client-side functions or steps of a business strategy configuration and execution method.

[0082] In one embodiment, a computer device is provided, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the computer program to perform the following steps: Upon receiving a policy change message, the system calls a stored policy parsing script to parse the policy change message, generates a policy model containing policy codes and policy configuration attributes, and stores the policy model in association with the product identifier. The policy code is associated with a pre-stored policy execution script. In response to a configuration request for a product identifier, the corresponding strategy model is obtained based on the product identifier, and interface rendering data is generated based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface. Receive business scenario parameters submitted through the policy configuration interface, generate policy filtering conditions based on the business scenario parameters, and associate and store the policy filtering conditions with the corresponding policy codes. Receive a business execution request, extract current scenario information from the business execution request, match the policy filtering conditions according to the current scenario information, and filter out a list of execution policies containing at least one target policy code; Traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request to the target strategy execution script for execution, and obtain the strategy execution result; The response information is assembled and returned based on the execution result of the strategy.

[0083] In one embodiment, a computer-readable storage medium is provided, which may be non-volatile or volatile, and a computer program is stored thereon, which, when executed by a processor, performs the following steps: Upon receiving a policy change message, the system calls a stored policy parsing script to parse the policy change message, generates a policy model containing policy codes and policy configuration attributes, and stores the policy model in association with the product identifier. The policy code is associated with a pre-stored policy execution script. In response to a configuration request for a product identifier, the corresponding strategy model is obtained based on the product identifier, and interface rendering data is generated based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface. Receive business scenario parameters submitted through the policy configuration interface, generate policy filtering conditions based on the business scenario parameters, and associate and store the policy filtering conditions with the corresponding policy codes. Receive a business execution request, extract current scenario information from the business execution request, match the policy filtering conditions according to the current scenario information, and filter out a list of execution policies containing at least one target policy code; Traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request to the target strategy execution script for execution, and obtain the strategy execution result; The response information is assembled and returned based on the execution result of the strategy.

[0084] It should be noted that the functions or steps that can be implemented by the computer-readable storage medium or computer device described above can be referred to the relevant descriptions on the server side and client side in the foregoing method embodiments. To avoid repetition, they will not be described one by one here.

[0085] Those skilled in the art will understand that all or part of the processes in the methods of the above embodiments can be implemented by a computer program instructing related hardware. The computer program can be stored in a non-volatile computer-readable storage medium, and when executed, it can include the processes of the embodiments of the above methods. Any references to memory, storage, databases, or other media used in the embodiments provided in this application can include non-volatile and / or volatile memory. Non-volatile memory can include read-only memory (ROM), programmable ROM (PROM), electrically programmable ROM (EPROM), electrically erasable programmable ROM (EEPROM), or flash memory. Volatile memory can include random access memory (RAM) or external cache memory. By way of illustration and not limitation, RAM is available in various forms, such as static RAM (SRAM), dynamic RAM (DRAM), synchronous DRAM (SDRAM), dual data rate SDRAM (DDRSDRAM), enhanced SDRAM (ESDRAM), synchronous link DRAM (SLDRAM), Rambus direct RAM (RDRAM), direct memory bus dynamic RAM (DRDRAM), and memory bus dynamic RAM (RDRAM), etc.

[0086] Those skilled in the art will clearly understand that, for the sake of convenience and brevity, the above-described division of functional units and modules is used as an example. In practical applications, the above functions can be assigned to different functional units and modules as needed, that is, the internal structure of the device can be divided into different functional units or modules to complete all or part of the functions described above.

[0087] It should be noted that any AI models, software tools, or components not belonging to this company appearing in the embodiments of this application are merely illustrative examples and do not represent actual use. All user personal information involved in the embodiments of this application has been authorized (with the knowledge and consent) by the relevant parties or has been fully authorized by all parties, and the executing entity may obtain it through various legal and compliant means. The collection, storage, use, processing, transmission, provision, and disclosure of the information, data, and signals involved all comply with relevant laws and regulations and do not violate public order and good morals.

[0088] The above-described embodiments are only used to illustrate the technical solutions of the present invention, and are not intended to limit it. Although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features. Such modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention, and should all be included within the protection scope of the present invention.

Claims

1. A method for configuring and executing business strategies, characterized in that, Includes the following steps: Upon receiving a policy change message, the system calls a stored policy parsing script to parse the policy change message, generates a policy model containing policy codes and policy configuration attributes, and stores the policy model in association with the product identifier. The policy code is associated with a pre-stored policy execution script. In response to a configuration request for a product identifier, the corresponding strategy model is obtained based on the product identifier, and interface rendering data is generated based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface. Receive business scenario parameters submitted through the policy configuration interface, generate policy filtering conditions based on the business scenario parameters, and associate and store the policy filtering conditions with the corresponding policy codes. Receive a business execution request, extract current scenario information from the business execution request, match the policy filtering conditions according to the current scenario information, and filter out a list of execution policies containing at least one target policy code; Traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request to the target strategy execution script for execution, and obtain the strategy execution result; The response information is assembled and returned based on the execution result of the strategy.

2. The business strategy configuration and execution method as described in claim 1, characterized in that, Upon receiving a policy change message, the system invokes a stored policy parsing script to parse the message, generating a policy model containing policy codes and policy configuration attributes. This policy model is then associated with and stored in association with a product identifier. The policy codes are linked to pre-stored policy execution scripts, including: Listen to the business message queue, and when a policy change message is captured, load the stored policy parsing script based on the operation type of the policy change message; Run the stored policy parsing script to perform field mapping logic on the policy change message and extract the policy code, policy configuration attributes, and product identifier; Encapsulate the policy code and the policy configuration attributes to generate a policy model; A mapping relationship is established between the strategy model and the product identifier, and the associated storage is performed. The pre-stored strategy execution script is retrieved according to the strategy code, and the association relationship between the strategy code and the pre-stored strategy execution script is established.

3. The business strategy configuration and execution method as described in claim 1, characterized in that, In response to a configuration request for a product identifier, the corresponding strategy model is obtained based on the product identifier, and interface rendering data is generated based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface, including: Receive a configuration request for a product identifier initiated by the front-end workbench, and parse the configuration request to obtain the product identifier; The database is queried using the product identifier as the search condition to obtain at least one strategy model associated with the product identifier; Iterate through the obtained strategy models, read the strategy configuration attributes in the strategy models, and obtain the component type, field options, and display order information; Assemble the component types and field options according to the display order information to generate interface rendering data; The interface rendering data is returned to the front-end workbench, where the front-end workbench configures the interface rendering strategy based on the interface rendering data.

4. The business strategy configuration and execution method as described in claim 1, characterized in that, The system receives business scenario parameters submitted through the policy configuration interface, generates policy filtering conditions based on the business scenario parameters, and associates and stores the policy filtering conditions with the corresponding policy codes, including: Obtain the business scenario parameters selected for the target strategy on the strategy configuration interface. The business scenario parameters include connection method information, business source information, and business type information. In response to the submission operation initiated by the strategy configuration interface, the configuration request containing the business scenario parameters is approved, and the approved business scenario parameters are extracted after approval. The approved business scenario parameters are logically encapsulated to generate policy filtering conditions that can be recognized by machines; Obtain the policy code corresponding to the target policy, establish a mapping relationship between the policy filtering conditions and the policy code, and write the mapping relationship and the policy filtering conditions into the policy filtering configuration table.

5. The business strategy configuration and execution method as described in claim 1, characterized in that, Receive a service execution request, extract current scenario information from the service execution request, match the policy filtering conditions according to the current scenario information, and filter out a list of policies to be executed that contain at least one target policy code, including: Parse the received business execution request and extract the current scenario information, including the interface channel identifier, business type identifier, and business source attribute, from the context of the business execution request; Access the policy filtering configuration table and retrieve the policy filtering conditions stored in the policy filtering configuration table; The current scene information is logically compared with each policy filtering condition to identify the matching policy filtering condition. Obtain the policy code associated with the matching policy filtering condition as the target policy code, and generate a list of policies to be executed containing at least one target policy code.

6. The business strategy configuration and execution method as described in claim 1, characterized in that, Traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request to the target strategy execution script for execution, and obtain the strategy execution result, including: Iterate through the list of strategies to be executed and read the target strategy code one by one; Based on the association between the target policy code and the policy execution script, a search is performed to obtain the target policy execution script that is associated with the target policy code; A script execution environment is constructed for the target strategy execution script, and the data to be processed in the business execution request is loaded into the script execution environment; The target policy execution script is run in the script execution environment to obtain the corresponding policy execution result.

7. The business strategy configuration and execution method as described in claim 1, characterized in that, Assemble and return response information based on the execution result of the strategy, including: Summarize the policy execution results generated by running all target policy execution scripts; Extract the feedback status and corresponding prompts from the aggregated strategy execution results; According to the interface specifications required by the business system that initiated the business execution request, the feedback status and corresponding prompt text are encapsulated into response information; The response information is then fed back to the business system.

8. A business strategy configuration and execution device, characterized in that, The business strategy configuration and execution device includes: The strategy modeling module is used to receive strategy change messages, call the stored strategy parsing script to parse the strategy change messages, generate a strategy model containing strategy codes and strategy configuration attributes, and store the strategy model in association with the product identifier. The strategy code is associated with a pre-stored strategy execution script. The interface rendering data generation module is used to respond to the configuration request for the product identifier, obtain the corresponding strategy model according to the product identifier, and generate interface rendering data based on the strategy configuration attributes of the strategy model to provide a strategy configuration interface. The strategy filtering construction module is used to receive business scenario parameters submitted through the strategy configuration interface, generate strategy filtering conditions according to the business scenario parameters, and associate and store the strategy filtering conditions with the corresponding strategy codes. The strategy filtering module is used to receive a business execution request, extract current scenario information from the business execution request, match the strategy filtering conditions according to the current scenario information, and filter out a list of strategies to be executed that contain at least one target strategy code. The strategy execution scheduling module is used to traverse the list of strategies to be executed, retrieve the target strategy execution script that is associated with the target strategy code, pass the data to be processed in the business execution request to the target strategy execution script for execution, and obtain the strategy execution result. The result encapsulation module is used to assemble response information based on the strategy execution result and return it.

9. A computer device, characterized in that, The computer device includes a memory, a processor, and a business policy configuration and execution program stored in the memory and executable on the processor. When the business policy configuration and execution program is executed by the processor, it implements the steps of the business policy configuration and execution method as described in any one of claims 1-7.

10. A computer-readable storage medium, characterized in that, The storage medium stores a business strategy configuration and execution program, which, when executed by a processor, implements the steps of the business strategy configuration and execution method as described in any one of claims 1-7.

Images